Version control: Difference between revisions

Source code management is one of the cornerstones of application development. When the time comes to manage the source code of a project you're working on, there are two ways to proceed. You could make multiple backup copies, send the source code to your colleagues by e-mail and waste time trying to remember who has or is using which version of the code and how to reconcile the modifications that each contributor has made. Alternatively, you could choose a much more rational approach by using a revision control system that has been specifically created to make this process as painless as possible.

Revision control tools offer you a great many advantages and these more than compensate for the occasional inconvenience. Firstly, they permit you to collaborate more easily. They eliminate the risk that a collaborator might delete your modifications or vice-versa without leaving a trace. These tools save the history of all the modifications made to a project and in that way function somewhat like a time machine, allowing you to re-initialize your project to an earlier version, in order to reproduce your results for example. They also make it easier to document these changes, so that all of the users of a project are notified of the changes made and the reasons they were made.

Source code management tools function using a basic principle of separating local modifications made by a user, in his or her local directory, and what is called the repository. The repository contains, in a structured manner, the history of all of the modifications made by all of a project's contributors. The development of a software project using a source code management tool is thus modified in comparison to the development of a purely ''local'' project. Rather than simply saving your modifications to the local disk drive, you as a contributor have to submit (''commit'') your modifications to the repository in order to make them available to other developers. Inversely, developers need to make sure they are using the latest version of a file by retrieving it from the repository (''checkout'', ''update'') before making their own modifications. If two programmers modify the same source code file at the same time, the source code management tool may report a conflict during the submission of the two rival modifications or automatically resolve the conflict if possible.  

The principal revision control tools can be divided into two ''families'' or ''generations''. First generation tools, which include [https://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [https://en.wikipedia.org/wiki/Apache_Subversion SVN], use a single central repository. All of the modifications are under the control of and retrieved from this authoritative repository. Second generation tools such as [https://en.wikipedia.org/wiki/Git_%28software%29 Git], [https://en.wikipedia.org/wiki/Mercurial Mercurial] and [https://en.wikipedia.org/wiki/GNU_Bazaar Bazaar], use local repositories. The advantage of such a system is that development work can be done independent of any remote server. The ''commit'' and <i>checkout</i> operations can thus be much faster and perform more complex operations. As an example, Git and Mercurial offer advanced management of branched development. In a branched development model, each new feature corresponds to a branch of the development tree. The <i>production</i> version of the project then corresponds to the principal branch and additional features are developed in parallel until they are sufficiently mature to be fused with the principal branch or else abandoned and the branch left to die. This development model is particularly well-adapted to very large projects involving several programmers.