Eight reasons for preferring Git instead of TFVC

A year ago I wrote a post with eight reasons to use the TFVC instead of Git in TFS. At the time, said he would write a companion post with arguments to give preference to Git instead of TFVC.

Well, it took but it was time. Here are eight reasons to prefer using Git instead of TFVC a TFS team project or of VSTS.

I must say that I really wanted to get to the point, but unfortunately I can't. This is because, first, I have to make a public admission.

Git is better than the TFVC. And point.

A lot of people lost his head when, in the "post-brother" this here, joked that the TFVC was better than Git. The internet has become increasingly a place of vigilantes sourpusses.

Well, to bring a little happiness to this horde of grumpies, is properly registered in this post that Git is better than the TFVC.

Oh, one important thing to point out: the idea of these posts was never compare the Git and the TFVC generic way, out of a specific context. On the contrary, the idea was that the context was very specific:

For a user to TFS to go create a new version-control repository, which option to choose? TFVC or Git?

Have you seen? The comparison is solely and exclusively within the context of TFS/VSTS users. If you don't use either of them, so maybe some of the points discussed in this post are not so relevant. Still, your comments are welcome!

With all that out of the way, I think I'm finally free to talk about what matters. Winking smiley Here are eight reasons for preferring Git the TFVC version control repository in TFS/VSTS:

De facto standard for version control

The war of version control repositories and Git won. Simple as that. Of course, the other will continue around for a long time; Subversion, Mercurial, CVS, TFVC, ClearCase, RTC Streams, Perforce and even SourceSafe (!) will still be around for a good few years. But the future is here and it's called Git.

That way, if you don't have any of the reasons mentioned in the previous post to keep the TFVC, this in itself may already be reason enough. Adopt the Git means giving a guarantee of longevity to your project that TFVC simply do not have as offering. Oh, if you are a developer and don't know Git, #ficaadica: you are getting obsolete faster than you think.

Lingua franca of the world open-source

Git was born with a very specific purpose: to serve as a version control solution for use by developers of the Linux Kernel – in fact, the creator of Git is Linus Torvalds himself. But the solution was so cool and flexible that ended up being adopted by other open source projects. This adoption by other OSS projects began to shy way but over time were replacing other commonly used open-source options – Subversion in particular. The major catalyst for the adoption of Git as the standard repository of OSS projects, however, was the GitHub. The concept of "social network for developers", with the free hosting of source code for open-source projects, isn't exactly new. SourceForge already existed and was well established when the GitHub emerged. However the user experience of the GitHub overcame the offered by SourceForge and other equivalent sites of the time. It didn't take long for him to overthrow them all (including the ill-fated CodePlex from Microsoft). I would hazard to say that the majority of open source projects, nowadays, is hosted on GitHub.

And what does this have to do with users of TFS and VSTS? Well, open source is something that has always been important in all communities of development – even the owners, as was the case of .NET until a little while ago. But that importance is increasing with each passing day; just watch the movements all of Microsoft towards the opening of the code of several of their products, and the integration with open-source solutions. Their development teams inevitably must interact with other open source projects sooner or later. Mastering Git now – use Git on a daily basis – means minimizing the friction that they suffer in their first incursions by typical concepts of open-source projects based on Git and hosted on GitHub. In addition, new developers are probably familiar with Git; offer a corporate repository Git-based decreases the time that dev does it take to integrate to your team, compared with someone who would need to get used to TFVC.

Distributed and decentralized

Who works with version controls centered-as is the case with the TFVC – usually die of fright from a fall of network/internet. This is because, if you get disconnected, they can't get more version source code. A DVCS (distributed version control system), on the other hand, does not suffer from this badly. Designed explicitly to support disconnected scenarios, Git allows developers to make a copy ("clone") of the version control repository on their individual machines. Thus, the commits can be made on your own computer, without relying on access to a centralized database. Once the set of changes made by the developer is ready to be integrated into the central repository, he "push" ("push") your changes.

On Lambda3, for example, that is particularly useful. Our development teams that serve remote clients do not require an online connection with the TFS client for to work. They clone the repository, do your work disconnected and, once they're ready, they integrate their work with the rest of the team doing the push for TFS. In other words, even if the VPN was unavailable for a while, they have not stopped working.

Frequent commits

The convenience to work disconnected and deliver the code only when ready (tested etc.) allowed developers to use Git to end creating a very healthy habit: Do frequent commits (sometimes in the dozens of commits per day), with small amounts of code. Therefore, review your changes (and back, if necessary) becomes much easier. In addition, features such as amend (the possibility of correcting the last commit, changing its contents), rebase (rewrite of history of commits) and squash (a combination of several commits into one) decrease the fear to create multiple commits, because the developer is free to change and adjust those commits at will, leaving them "bubble" to the time of integration.

Branching and merging more simple and efficient

Who doesn't have a dread of merges? I assure you that every user of TFVC hasAlegre. This is, in my view, one of the greatest benefits that Git brings compared to the TFVC: your branching and merging algorithm is much more efficient than the TFVC, considerably reducing the amount of conflicts that in TFVC would have to be resolved manually.

Pull requests

Another very cool feature of Git when used inside the TFS/VSTS, the pull request corresponds somehow to code review the TFVC. Is one of the coolest mechanisms to help teams improve the quality of your code, because it stimulates the peer review. On Lambda3, for example, there is an agreement in most development projects: any developer makes push straight into the master branch. Integrations should happen via pull requests. That way, other developers on the team have the opportunity to review the code before integrating it, minimizing the risk of integrating code with problems. In addition, the functionality of pull requests offers several conveniences such as the display of the status of the last build of CI (build broken, pull request rejected), the history of discussions (with the tips of fixes/improvements) and merge (if possible of course).


Many people still see TFS/VSTS as a .NET project control solution, even in years that's not true. However, even though Microsoft offers a cross-platform client to the TFVC (known as Team Explorer Everywhere) it has its limitations. Already Git, on the other hand, is supported in virtually all operating systems and is integrated to most IDEs and text editors for programmers – even Git written in Javascript. By adopting the Git in TFS/VSTS, you make life easier for your teams who work on non-Microsoft platforms, such as iOS and Android developers.

Git Flow

Another common complaint from TFVC users is "How should I structure my blank template?" In the absence of a standardized and consistent model, each time "invents" a different model of work that often more hindrance than help. With Git, you do not need from scratch. Instead, you can use the process known as "Git Flow" – a simple process, efficient and well-documented blank and management of releases to Git. Like any process, there are those who love and those who dislike. Evaluate it to see if it fits your team work model. But it's better than "inventing" a template from scratch, inside the House. In addition, the chances are great that new hires in your team meet Git Flow, helping again to reduce the initial onboarding friction of a new Member on the team.

The end of "love it or leave it"

Oh, this is really cool: recently the choice by Git or TFVC ceased to be something drastic, like "till death do us part". In the old days, when you create a team project in TFS/VSTS you choose a format of version control repository and was stuck with him for the rest of the life of that project. Now, it is possible to host Git repos and TFVC in the same team project. This provides more flexibility at times, you can choose the format of the repository that best they see fit.


What did you think of the post? Be sure to comment!



A hug,

Author: Igor Abade

Igor Abade V. Leite ([email protected]) is a Visual Studio ALM MVP (Microsoft Most Valuable Professional) since 2006. Speaker at various Software Development community events (TechEd Brasil, The Developers’ Conference, DevOps Summit Brasil, Agile Brazil, Visual Studio Summit, QCON among others), has also written articles in magazines and websites such as MSDN Brazil. Since March/2011 is one of the owners of Lambda3, a Brazilian consulting company specialized in ALM, software development and training. Visit his blog about VS ALM at http://www.tshooter.com.br/ and follow him on Twitter @igorabade.

Leave your comment!