What's this?
Git is a DVCS, a Distributed Version Control System. What is this, and what's its purpose?
A CVS allows to store all changes that you perform on a project, by creating commits. Every commit corresponds to a specific project state. In general a CVS stores only the differences between different commits, allowing to save space and time while storing them. So the first advantage is that you can store different versions of your program without having many folders named newrelease, newerrelease, thisisthelastrelease, somefixafterlastrelease-2 and so on. It's easier to retrieve a previous state, if needed.
For this, it's possible to define tags, that are like bookmarks to a specific commit. So, if you're ready for production, you can tag the specific commit, so at every time is possible to take that specific commit with that specific code, if needed.
Another important feature of a CVS is collaboration. In fact, it allows different people to work to the same project easily. Many developers can work on the same project at the same time. When one developer make some changes, they will be available to other developers. It perform automatically merge of work, so at every moment people can work with the most updated code.
There are some specific points that explain why a CVS is really useful for development:
- History: Every project file is tracked. It means that you can change it without worrying about losing data. If the file does not work, simply discard changes and return to the previous version. It's also possible to retrieve files that you've deleted before. All this without maintaining hundreds of folders with many copies of the project;
- Collaboration: Not only you track file changes, but you track also who changed what. Many people can work at the same project without worrying about synchronization of the project. Instead of exchanging data manually between developers, you simply use the CVS for storing your data. When other developer needs to update their local copy, instead of asking to everyone around the office, they simply take changes from CVS;
- Merging: In order to collaborate, it's necessary for a CVS to handle also merging. Many developers can work on the same file at the same moment. Without a CVS, for example using a FTP server, a developer made some changes and then stores the file. Then another developer, that were modifying the same file, send it to the server overwriting the last one. Changes are lost. Using a CVS, it take care about it and (if possible), resolve conflict automatically, so when I update a file, instead of overwriting the existing one, it will be merged, so in the final result, modification from all user are stored and anything is lost;
- Branching: A branch is an isolate copy of your project that can evolve in an independent way from the main one. You can create a branch, work on that branch to a complex issue and, when that issue is ready, you can merge the branch to the original one. Other developers does not take care of your branch, so they can continue to work to a version that is not a WIP, and it's working. It's also possible to have a main branch that contains all main work, and then specific branches for different customers, in which there's the base code and some specific personalization;
- Tagging: When everything is ready and working, is possible to create a tag. Tags links to specific commits so, while we can continue to develop the project, it's always possible to retrieve the code for the release, for example if we need to fix a production bug but we don't want to introduce yet the new code.
These are only a few advantages in using a CVS. We'll see in this series how many things we can do. You'll never create a "almoststableversion" folder for your project!
The power of D
In previous section we used CVS instead of DCVS. There's a specific reason. Until some time ago, there were only CVS, like Subversion. They were powerful, but with a limitation: the necessity of using a central server for storing the repository. This is not a limitation in a strict way: it works well, but every piece of work that you made must be stored in the central repository. Sometimes you don't want that, for example if you are working on an incomplete feature. D means Distributed: this means that every people has inside its PC the entire project, and it can commit works locally without the necessity to be linked to a central repository. So you can made all changes that you want, modify these commits (we'll see later it) and work also offline.
There are a lot of other benefits, and it allows a great flexibility especially in big project management. For example commit is faster, because you don't need to use every time a remote repository, but you can send your changes only once in a while, when needed. You can work offline, without the necessity to stay always connected to a remote server in order to commit changes. There's also no central server. Usually there's one, but if you need you can also take changes from a colleague PC storing the same project, if you want his changes but they are not stables for sending them in the central repository. There are a lot of possibilities.
Conclusion
As you can see, we only briefly introduced Git. We'll see how to work with it in next articles. Bye!
