Kendra Little

1 March 2021

Why to Use Git Instead of “TFS” (TFVC)

One question we frequently hear from customers using the Microsoft stack is, “should I use Git or TFS?”

The question requires a little decoding due to the way that Microsoft has shifted their brands over time. Here’s some background:

Microsoft’s “Team Foundation Server” (TFS) was renamed “Azure DevOps Server” in 2019

Many people still refer to this as “TFS,” regardless of the version they are using.

Azure DevOps offers two options for versioning your code in a repository (“repo”)

• Git
• Team Foundation Server Version Control (TFVC)

TFVC used to be the default type of repo for TFS projects. This has led many people to combine the terms for the two and refer to the TFVC repo as “TFS.”

The question above usually translates to: “Should I use a Git repo or a TFVC repo with my Azure DevOps Project?”

I strongly recommend you choose a Git repo. Here are three reasons why.

1. Microsoft recommends Git Repos

One of the first things to know is that Microsoft has made Git the default version control for new Azure DevOps projects (whether Server or Services).

Microsoft has documented:

Git is the default version control provider for new projects. You should use Git for version control in your projects unless you have a specific need for centralized version control features in TFVC.

Choosing the right version control for your project

In other words, if you have a very specific reason why you need to continue using TFVC, Microsoft would rather you didn’t.

They haven’t cut off support for this or marked it is as deprecated, but you should use Git for new projects.

(I think the implication of what might happen in 3-5 years is pretty clear here.)

2. TFVC customers are rapidly moving to Git

Git has very much become the default choice for version control for software development in general. We are users move to it from all other types of version control, including TFVC.

Redgate’s David Atkinson has regularly run polls regarding VCS usage on SQL Server Central since 2008. Given its focus, SQL Server Central naturally draws views and interactions from Microsoft customers. These polls have a good sample size, with generally between 350 and 1,000 respondents per poll.

Here is the data regarding VCS choice over the years:

Customers are rapidly moving away from TFVC, Subversion, and other version control systems and adopting Git for version control.

Note that this does NOT indicate that customers are moving away from Azure DevOps Server (formerly “TFS””) or Azure DevOps Services (formerly “VSTS”) — as mentioned above, Git repos are now the default for Azure DevOps Projects and are recommended by Microsoft.

3. Your VCS is the foundation to automation

It’s natural at this point to ask, “so everyone else is doing it — why should we?”

There are a few reasons to move along with the tide.

It’s easier to implement workflows and automation based on a pattern

Workflows are important. How to team members share work? When does automation kick in to help validate that work? How does code progress through environments before making it to production?

When starting a new project, it is much easier to choose a popular workflow and customize it to your own needs — as compared to coming up with an entirely new workflow. Existing workflows have many benefits:

• The workflow is often documented in many user blogs, along with common customizations
• Tricky aspects to the workaround have been documented online along with workarounds
• Many users of sites like StackOverflow are knowledgeable about the workflow and eager to answer questions about it

Git has many popular workflows and a rich community built around automation and these workflows. TFVC does not.

Knowledge of Git is increasingly expected of developers and IT staff in the industry

Git has become so common that most developers and DBAs have come to see it as required knowledge to advance their careers — both inside their current organization, and in their career as a whole. TFVC is increasingly seen as a legacy version control system.

While working with legacy systems is sometimes unavoidable, in the case of version control systems we are seeing people rapidly move to Git. This is likely because…

It’s best to standardize on a single type of VCS in an organization

Between technical knowledge and understanding processes and workflows, developers and IT workers have to remember a lot of details. Understanding more than one version control system and their related workflows is a lot to ask of folks.

For this reason, most organizations choose to centralize on a single type of VCS. This means:

• Engineers can work on multiple projects and not have to maintain knowledge of multiple types over version control
• The ramp-up time for people moving between teams is lower
• It’s easier for teams to collaborate and share knowledge, workflows, and code
• It’s easier for central IT staff to support a single type of repo when self-hosting, and to document and manage permissions for a single type of repo when cloud-hosted

Git has very much become the default organizational standard for VCS, both for Microsoft customers and in general.

Getting started with Git

I’ve written a few posts to help with ramping up with the Git VCS:

• The Manager’s Guide to Git Training for Database Administrators
• Learn Git with the LearnGitBranching Website (Recommendation and Video)
  My Git and VSCode Setup: Global Git Config, Extensions, and More (Video)