For developers evaluating version control software, there are realistically three primary contenders: Git, Mercurial and SVN. Git and Mercurial offer distributed version control (DVCS), while Subversion is one of the leaders in centralized version control. Between Git and Mercurial, Git is currently leading the way as the version control system for the Linux platform and GitHub, one of the most popular online software repositories for new open source projects.
What is centralized version control?
The concept behind centralized version control is relatively simple. When developers need to work on a change to a project, they first Check Out the project from a centralized repository on a company server. After applying their changes, they then Commit the project and its changes back to the repository. If someone else changed the project in the meantime, they need to perform a merge, by downloading the updated changes, testing, and committing back to the repository. The interaction diagram is as follows:
Developer Work Folder --> Centralized Server Repository
Below is a quick overview of the primary SVN operations:
- Check Out – Download latest version from the server
- Commit – Save local changes to the server
- Merge – Combine server changes with local changes
What is distributed version control?
Distributed version control, on the other hand, adds an extra step:
Developer Work Folder --> Developer Local Repository --> Centralized Server Repository
There is also an additional “Index” that holds meta data on the work folder, however it can be left out for the purposes of this overview. The developer will first commit to a local repository, which acts as a mediator between the work version and the centralized server repository. The local repository enables developers to commit interim changes, without breaking code of other developers on the centralized repository. Finally, before committing to the centralized repository, developers can finalize the code, edit previous revisions if necessary, and make sure that everything looks great before sending it to the centralized repository to share with the rest of the team.
The local repository also makes it easier to perform Merge operations. In fact, there are two kinds of Merges with Git, forward merges and backward merges. Forward merges take the local work version as the base, and add the updates from the centralized server as the changes. Backward merges, or Rebasing, takes the latest version of the centralized server copy as the base, and applies the local changes on top of those that have not yet been committed to the server.
Below is a quick overview of primary Git operations:
- Commit – Save changes from local work folder to local repository
- Push – Move changes from local repository to centralized server repository
- Fetch – Retrieve changes from centralized server repository to local repository
- Pull – Retrieve changes from centralized server repository to work folder
- Merge – Get latest changes from server and add them on top of work folder changes
- Rebase – Get latest changes from server, and add local work folder changes on top of those changes
This extra level of repository adds new flexibility to version control workflow. What Git does not do:
- Git does not remove the necessity for backups. Probably one of the least intelligent arguments for using Git. Yes, if you have Git, you still need to back up your centralized repository.
- Git does not put all control in the hands of developers and cause companies to lose control of the centralized repository. Any business can and will make sure that the code in the centralized repository is well maintained.
- Git is not more insecure than SVN. SVN still stores most of the repository onto the local developer PC in a work folder. Git just makes it easier to work with that offline repository.
Written by Andrew Palczewski
About the Author
Andrew Palczewski is CEO of apHarmony, a Chicago software development company. He holds a Master's degree in Computer Engineering from the University of Illinois at Urbana-Champaign and has over ten years' experience in managing development of software projects.
Google+
