Why I Chose Git over Team Foundation Version Control (TFVC)

Back in 2014, our team was in desperate need for a project management overhaul. If you could imagine: we were juggling between waterfall, agile, and random e-mail chains. Our code was split between a subversion repository and just living only on the production servers. No one knew what people were working on, or what was coming next. This is one of those nightmares hidden in every development teams’ closets.

Visual Studio Online To The Rescue

At that time, Visual Studio Online was in beta and was the solution to most of our problems. It allowed us to put all of our repositories in one location. It allowed us to create a workflow and start continuously integrating to each of our code environments. Finally, it allowed us to follow agile practices with task cards and a kanban board.

When we made the decision to move over to VSO, the only version control providers available were TFVC and Mercurial. Git would come later that year.

Never Be Afraid of Change

Just over a year later, it was time for a change. TFVC worked great for simple applications and smaller teams, but it is not the best for a continuous delivery team who needs to constantly push changes out the door and create branches left and right.

We stayed with Visual Studio Online, but moved all of our repositories to Git. This allowed us to use some slick features VSO only had available to Git, such as a real release management pipeline.

Downfalls of TFVC

There are three main downfalls I’ve come to see with using TFVC over Git for larger teams.

1. TFVC has a heavy branching strategy. This works fine if you have a small team when everyone is working in the trunk and create a feature branch every once in a while. When you have a larger team which needs to create bug and feature branches constantly, this is very time consuming and also can take up a lot of disk space, depending on how many branches you have.
2. No way to create a release pipeline without branches for each of your code environments. I found it rather difficult when first designing our release pipeline in the summer of 2014 with TFVC. The build process with Microsoft’s tools and its Release Management software was pretty simple, but when it came to continuously integrating code into 3 different environments (development, testing/QA, and production) didn’t make much sense outside of creating branches for each of those for the code to live on. We needed to be able to create a build and artifacts initially for our development server, then easily be able to promote them to the next environment as they became ready. This simply wasn’t possible with TFVC. Luckily with Git, this became much easier to do with VSO.
3. The backbone of the process lay on a couple of people to manage build and merge requests. In order for the process to work correctly, there was a lot of manual labor involved. People were allowed to branch and check-in code changes at their leisure, but when it came time that one of their bug or feature issues were ready, they had to request their code be merged in from their branch to the release pipeline. Once that was done, then they had to again request their code be merged into the next environment, and so on until it was in production. This was very time consuming at first, but as time went on it became less and less and more easy to do. Unfortunately, the beauty of a real continuously integrated, continuously delivered product is that no middle man be needed at all.

We are now using Git in this fashion:

1. Every single code change is done in a branch. Whether it’s a bug fix, feature request, or refactoring, it is all done from a merge off of the master branch. Branching in Git is super fast and easy.
2. The master branch is not allowed to be directly committed to. All changes to the master branch must be merged in for a pull request. This allows for optimal code quality by insuring accountability.
3. Release pipeline queued upon merge to master branch. Once a pull request has been approved and merged back into the master branch, a build will be queued and started to our QA servers. Once it has been approved by testers and the QA team, it is then queued to be moved into production immediately.

Switching to Git and adding pull request code reviews to our development pipeline has really allowed our team to harmonize together, know what everyone is working on, and help each other be the best developer they can be. Ultimately, we are getting quality code delivered faster.