Git, got it, know it’s good: Dev team finds version control solution
A version control system is one of the most significant tools used by a development team, and a solid source control system and strategy are essential for effectively managing large teams of developers.
For several years Microsoft’s Team Foundation Server hosted most of the source code at Getty Images. TFS offered a clear and easy solution given that much of our development is done on the .NET platform. TFS has first class integration with Visual Studio (great for devs), is backed by SQL Server (great for backups and our DBAs) and has single-sign-on via Active Directory integration (great for IT). However, as our development practices have evolved, TFS has created a lot of friction for us with its approach to source code management.
As we increase our flexibility and agility we need our tools to empower our development practices… and TFS offers a very heavyweight model which impeded certain aspects of our development.
In a search for alternatives, one of our development teams decided to try Mercurial, a popular distributed source control system. The result was so positive that we began looking at ways to roll out a solution to the rest of the company. Eventually we chose Git due to its more flexible branching model along with the greater momentum it has in the industry. Momentum is a key factor for us. We want our developers to have enough resources available to accelerate this transition.
Git is proving to better match our needs as we increase collaboration and move to more frequent release cycles. Below are three specific areas where Git excels over TFS: branching, decentralized management and a read/write file model.
The TFS branching model is very heavy. Creating a branch requires specific permissions from the system administrator and involves creating a complete copy of every file in the repository at another location. For our larger repositories at Getty Images, creating a new branch would take several minutes. Creating the branch in another physical location adds a level of friction for web projects, as the IIS mappings need to be updated to point to the branch location. Merging changes is not any easier.
On the other hand, branching in a distributed source control system like Git is extremely easy. It takes less than a second to create a branch, and a developer doesn’t need to think twice before doing so. This allows quick spikes to code with a definitive recover point. This works for teams as well; they are now able to collaborate together on a short-lived feature branch and then merge the branch when the feature is ready to share with others. Since the branch is created in the same working directory, you do not need to remap IIS when you switch branches. Everything is fast and easy.
Centralized vs. Distributed
We ran into issues with the centralized nature of TFS. This was a particular issue for our georgaphically diverse distributed development teams. Developers are discouraged from committing their changes until they are completely done. They do not want other developers working against their partially implemented code. This often has the effect of subtly discouraging risk-taking and creativity. In addition, work can be lost because there is no intermediate undo point. Developers usually resort to shelvesets to try to address this, but shelvesets have their own limitations.
With Git, every developer has their own copy of the entire repository. They can create a branch to simply try something out. If it doesn’t work the way they want, they can simply throw the branch away. If it does work out, the developer can share the branch with other people for code reviews, enhancements or problem solving. Those changes can ultimately be merged into the master branch. There is a lot of flexibility with Git’s branching model that enables all kinds of workflows that were previously too hard to do with TFS.
TFS marks all files in the repository as read-only by default. In order to start editing the file, one needs to “check-out” the file, and only then will TFS clear the read-only bit. While working in Visual Studio, this is taken care of behind the scenes – so it’s not that big of a deal. However, not all of our development is done inside of Visual Studio. It’s not uncommon to make a quick change to a build script, a css, js, or html file or even some c# code without wanting to fire up the entire IDE. The read-only lock combined with file additions/subtractions are difficult to orchestrate outside the Visual Studio GUI.
With Git, all files in your working directory are writeable. You can simply start making any changes you want, and let Git figure it out at the end when you are ready to commit. It will even detect when you have renamed or moved a file, allowing developers to easily make changes outside of Visual Studio using just a basic text editor. This creates a fluid integration with designers and front end engineers who can use the tools they want rather than be forced into VS and TFS.
Despite all of its advantages, there have also been some challenges in moving to Git. A majority of our development is currently done on Windows, which isn’t Git’s most natural platform. Many of the developers are used to a rich and clean GUI, and the command-line nature of Git has been an adjustment. While Git has a number of nice GUI tools available for free on other platforms, the Windows tools are still a bit rough around the edges. The other challenge we had initially was that the security team preferred we lock down our canonical repository with active directory credentials. It took some time for us to find a tool (Gitolite) which allows us to use Active Directory groups to manage the permissions of each repository.
We are still in the process of rolling out Git to the whole company. It is a significant paradigm switch from TFS, so we are carefully training every team when they are ready to make the switch. The training required — and the fact that we have hundreds of source repositories – means this change will not happen overnight. But most of the feedback has been positive so far, and we are confident this change will help us deliver software quicker — which ultimately means happier customers.
Andy Alm is a Principal Engineer at Getty Images