Why you should abandon TFS and adopt Git

Almost every time I do some kind of talk somewhere, people ask me for advice on how to convince their management that they should drop Microsoft Team Foundation Server's source control system and move over to Git. In this post, I'll be talking about the source control system only. Both Visual Studio Online (Microsoft's TFS-in-the-cloud), GitHub and BitBucket support this heavily. We use GitHub ourselves, but I've noticed that Microsoft made some considerable improvements since we moved away from TFS.

Anyway, in January 2014, after three years with TFS, we finally moved to Git. With 1.5 years of experience, I think we're entitled to having an opinion about how they compare. To help me compile this post, I asked my colleagues about things they can do now they couldn't do when we were still using TFS's centralized source control system. One word of disclaimer though.

• You can create and merge branches in seconds rather than minutes (or hours if your project is anything but trivial). Switching between branches happens in milliseconds rather than the typical 15-30 minutes in our projects. This completely changes the way you work. It allows a level of isolation that is inpossible to achieve with a centralized source control system.
   
• Pull Requests (PR), a feature supported by all online Git platforms is a crucial tool for teams to break down complex software systems in components owned by teams without blocking anybody. It allows developers to make a kind of copy of projects they don't own, create branches, work on improvements and new features, and then send a request to the owning team to pull in their changes. Pull Requests are the single best way to scale a software development organization into multiple autonomous teams.
   
• How often did you encounter useless comments like "Oops, I broke the build" or "Some review rework". You can clean up the history of a feature branch before you merge it to its final location by using an interactive rebase to amend existing commits (the equivalent of a TFS changeset), squashs a couple of commits together, or to fix up those commit comments.
   
• Developers can work in parallel on the same branch by merging with other team members, either from the central repository or on forks owned by individual team members. If they want, they can use PRs to control what gets in the shared branch.
   
• So you've worked on that feature for a week or so, but in the mean time, the main development branch has been changed considerably. Wouldn't it be cool if you could apply your changes on that newer branch as if you started from that version in the first place? Well, that's what a Git rebase can do for you. It keeps the history clean and avoids all those unreadable merges.
   
• Compared to our time with TFS, we have much less merge conflicts now are on Git. The main reason is that Git does a three-way merge because it knows exactly where two branches started to diverge. TFS typically does a pretty dumb text-based merge. You also have a lot of control how merging should be handled per file type in that particular project.
   
• You never have to check out anything explicitly. Just edit it the file in whatever tool you prefer and Git will pick that up. The project's .gitignore file ensure it will only monitor specific files. If the net result of your changes is that you didn't make changes at all, Git will not see that file as changed anymore. Say goodbye to all those TFS changesets with unmodified files. We did try TFS's Local Workspaces feature, but that collapsed with large repositories.
  
  

• Everything you can do online you can do off-line. Last year, I was traveling through Switserland for a couple of days. The simple fact you can branch, merge and rebase, all from your local laptop is something you really start to value if you can do that without an internet connection. This has become instrumental when the internet connection of my client's project went down. You can even merge with another colleague's repository over a local network share or USB drive.
  
  

• Since Git treats branches as a pointer at a linked list of commits, the entire source code, including all branches and tags can be downloaded in minutes, if not seconds.
  
  

• And finally, even Microsoft made the jump. Git is now the primary source control system for the on-premise version of TFS as well as Visual Studio Online's. And Microsoft is maintaining the entire .NET framework on Github.
  
  

If you still can't convince your boss with these arguments, tell your boss how much more productive you can be with Git. Or you can reverse that argument by telling him or her how much money he's throwing away every day by sticking with a centralized source control system.

So what do you think? Are you moving over soon? Did I miss any good arguments I should include? Did I exaggerate with any of this? Let me know by commenting below or tweeting me at @ddoomen.