SVN, Git Out of Here: How to Choose Your Version Control System
In recent years, the use of Git has risen tremendously popularizing distributed version control systems. According to an Eclipse community survey, in 2014 Git finally surpassed SVN as a Version Control System (VCS) of choice for Java developers.
Hosting platforms such as GitHub and Bitbucket have made distributed version control possible by providing the development community hosting space and tools. Microsoft has made Git the default version control provider for new projects in their TFS platform and strongly encourages developers to use Git unless they specifically need a centralized VCS. So how do the most popular VCS compare in their implementation of feature branch models and their level of convenience?
Selecting a Version Control System to Fit Your Needs
When a team begins a new project or reaches an inflection point in an ongoing initiative, it provides the opportunity to ask, “Is my current version control system working?” “What are the differences between Git and SVN?” We will explore three of the most popular version control systems — Git, SVN and Mercurial. From an ideological point of view, Mercurial and Git fall into the same category of distributed VCS. What are the major differences, and why do we choose Git?
Distributed vs. Centralized Version Control Systems
First came the centralized version control system with RCS (1982) and its successor CVS (1987). Currently the most popular are Subversion, TFVC, Perforce and Clearcase. Using these systems all developers access a single central repository. If a change is made, it will reach every developer before they can commit their changes and unfortunately, that also includes broken code. Since there is only one “true” repository, working offline can be a challenge. In order to complete basic operations like adding the viewing history or committing code, you need access to the repository.
One of the first distributed version control systems was Bitkeeper (1997). Current popular tools include Git, GNU Arch and Mercurial. In the distributed model, every developer has his/her own copy of the repository. Using this approach, developers can work offline — they can commit, branch, merge branches, view history, anything they need as they have the whole repository at hand. Internet access is needed only when synchronization with the other team members occurs.
Differences Between Mercurial and Git
Two major differences exist between Mercurial and Git.
Monolith. Mercurial comes as a monolith app, whereas Git, following the linux ideology, comes as a number of small binaries that often remain hidden to the developer. Having the fine tools to be able to tweak the system means Git is extremely flexible. Accuracy and flexibility are important to clients. So, having the flexibility to implement nonstandard solutions can be a game changer.
History. The other difference between Mercurial and Git is how they deal with history. Git allows (and some may say encourages) users to rewrite the history of their repository when they want to. This allows for the commit logs to be carefully adjusted to keep the log simple and logically structured rather than encompassing the whole history as it happened. With great power comes great responsibility, so history rewrites should happen only on local commits.
In the end, both systems are very similar. Additionally, many of the features Git provides out-of-the-box are brought into Mercurial as plugins. The feature branch workflow can be implemented easily in both Git and Mercurial.
Pros and Cons Implementing the Feature Branch Development Process with Git
Branching in VCS allows us to create a virtual copy of the code in order to make changes without affecting the original code. In the feature branch model, we want to have a separate branch for every new feature. There are several important benefits to this.
Pro: Easy Code Reviews Prior to Merging Code
Code reviews are great. They help keep the code uniform, maintaining the same style and significantly reducing the need for refactoring to bring code into alignment with standards. Occasionally, code reviews can also catch bugs even before the issue is transitioned to a quality assurance analyst saving precious time during the development process.
Pro: Better Control Over the Source
What makes the feature request approach so popular is the isolation it provides. Features are incubated separately from code and do not impact the codebase before they are ready. Although SVN provides branching, temporary branches are used only for bigger features due to their price tag on large projects.
Pro: Easy Transitioning Between Issues
Often, developers will need to pause and pivot working between different issues or tasks during the process. Suppose a developer has been working on an issue for about a week when a critical new fix is needed on production. Sure, he can do an SVN patch or do a clean download of the source code in a new location, but these workarounds will cost time and potentially cause frustration. Using the branch-per-feature workflow, all this work can be done with a simple temporary commit and a branch change.
Pro: Better Release Process
The feature branches line up neatly with the quite popular Git Flow. It accounts for all possible scenarios like hotfixes, code freezing and others.
Con: Complex History Log
As for the cons, they come from the additional steps that the developers must complete. Developers must make sure they branch from the right commit. Depending on the merging strategy for the completed issues, the history log may become bigger and harder to understand.
Differences Between Git and SVN
One of the most notable differences when switching to Git is its speed. Since the whole repository is stored locally on the developer’s machine, he or she can work for days with a very poor internet connection. Creating branches is lightning fast due to Git’s branch implementation. In Git, a branch is simply a reference to a commit, where the following commits will be attached. It doesn’t contain even basic information like create date, user who created it or some kind of a message.
Since Git encourages the use of branches, we can’t forget to give a shout-out to its merge capabilities. SVN before version 1.5 only did two-way merges that involved a change set applied to the current codebase, because it didn’t store merge information. Git uses the history of the repository to identify the common base between the merged branches and only needs to merge from where they diverged — thereby completing a three-way merge. SVN is also improving and has supported three-way merging since 1.5. In the upcoming 1.9 version of SVN, it will also have better rename/move tracking of files, something that Git already does.
Download: How to Integrate Your Distributed Development Team
Integration with Other Software
SVN has operated for over 15 years and thanks to its popularity has been integrated on most of today’s integration servers, issue tracking systems, IDEs and others. When considering the differences between Git and SVN, despite being 5 years younger than SVN, Git is by no means behind. It’s easy to integrate it with other software. Git itself provides only command line tools, but many companies have created various UI on top of it like Atlassian’s SourceTree, Github, Git Extensions and others.
Adopting Git
When weighing the differences between Git and SVN, Git offers few cons. Among them is the slightly steeper learning curve, at least in the beginning. If the developers on a project have worked only with centralized VCS, they may face some slowdowns navigating some of the differences, like the synchronization process and the added staging step when creating a commit. As mentioned, there are many GUI applications that can make the life of a developer easier and, if needed, they also provide command line interface in case more advanced commands are needed.
Not ready to switch to a Git repository yet, but still want to use a feature branch approach?
Git provides a tool called git-svn, which allows tracking a standard Subversion repository and provides a bidirectional flow of changes between them. You have the ability to work with feature branches and synchronize with the SVN repo’s branches when you need to. All this does not impact the team whatsoever as only the developer knows he is using a Git repository locally. Microsoft have adopted a similar approach with TFS. They have provided a git-tf tool which enables the ability to track a TFS repository. However in this way, the feature branch model is not utilized to its full potential as the management of the project cannot benefit from it.
Feature branches provide isolation and convenience. Thanks to the internal implementation of Git, creating branches — one of the expensive operations in SVN — is basically “free of charge.” This allows for instantaneous creation and cleanup of the temporary branches for creating new features.
Innovate with us. Click here to access all of our free resources.
Authored by Vasil Nonchev.
