With apologies to Harry Hill, we won’t be having a fight to find out because choosing between Git and Team Foundation Server (TFS) is no longer mutually exclusive. Version control is probably the single most important piece of the development environment after the IDE itself, essential for teams and I’d argue extremely valuable even for a solo developer. So, if you’re about to start a new project it’s a good time to consider what version control solution you’re going to use.

As an MSDN subscriber you’ve already got access to TFS, which provides the sophisticated and very scalable Team Foundation Version Control (TFVC) together with a fully integrated Application Lifecycle Management (ALM) solution to provide work item tracking, agile planning tools, a build engine and more. There’s also Team Foundation Service, which is TFS hosted in Azure. Team Foundation Service is incredibly easy to use, with no installation and is free for small teams up to 5 or with MSDN. There are some differences between TFS and the Service, but not regarding version control and for these purposes TFS will refer to both the on-premise and on-line versions.

But you might also have an interest in a Distributed Version Control System (DVCS) like Mercurial or Git. These offer a different model, particularly for off-line usage, but don’t provide the ALM capabilities and integration that TFS does.

So, do you have to make a decision between a stand-alone DVCS solution or TFS? No. You can go with either or a mix of the two, so let’s run through the options to help choose the right tool(s) for your situation.

Visual SourceSafe (VSS)

Just in case you were thinking about it, don’t; VSS is now out of mainstream support and doesn’t offer the capabilities of any combination of Git and/or TFS. So, let it go and move on… (or migrate using the tool provided in TFS).

TFS with Team Foundation Version Control

TFS provides a ready integrated combination of version control, work item (requirements/bugs/etc.) tracking, Agile planning tools (Product Backlog/Sprint Backlog/Task Board/Kanban Boards), automated build engine, test case management, reporting, dashboards and dev-ops integration. For developers, TFS has integrations into Visual Studio and Eclipse (and Eclipse based tools such as Rational Application Developer) as well as a cross platform command line tool for non-Eclipse users.

Team Foundation Version Control (TFVC) provides a very capable and scalable version control solution. There are two models available within TFVC:

  • Check-in Check-out with server workspaces

This, original, model provides tremendous scalability for very large codebases together with fine level control and auditability. Checking out requires a connection to the server and offline editing is more difficult, and outside of Visual Studio even more so.

  • Edit Commit with local workspaces

Local workspaces were introduced in TFS 2012 alongside server workspaces and allow for much improved offline support. With a local workspace you can checkout locally, edit, rename and delete all without a connection to the server. It’s also much easier to work outside of Visual Studio in another tool as this model doesn’t rely on file attributes but instead on metadata held within the local workspace.

TFS using TFVC will suit teams that require any combination of large codebase support, fine permission control and where working offline is the exception rather than the rule. It will support any mix of Visual Studio and Eclipse developers, allowing them to share the same repository and ALM capabilities.

TFS with TFVC, with either model, is still centralised, so a developer working locally without a connection to the server has some limitations such as not being able to create branches, merge changes, view history or perform compares without the server connection. In other words, TFVC is not a DVCS, and if that’s what you need then you’ll probably be looking at the most popular DVCS tool, Git.


Git arose from the Linux kernel development community (including and in particular Linus Torvalds) in 2005 and has become the leading DVCS tool. It has a totally different model to centralised version control systems like TFVC by keeping a full repository locally on the developer’s machine. The repository is essentially a file based system with metadata in hidden files. The developer can then perform any task offline, including checking out, editing, committing, viewing and diffing on the full history, creating and destroying branches, merging and more.

At appropriate points the developer’s local repository can be synchronised with a remote repository either by fetching, pulling or pushing changes. This, of course, does require a connection to the remote repository.

Git is popular with Open Source teams, who are typically highly distributed, and suits modular codebases where individuals can work entirely locally for extended periods.

Most of the Windows Git tools are command line based, but Visual Studio also has Git integration, either via the Visual Studio Gallery or in 2013 it’s out of the box. Here are the options after choosing to add a solution to source control:


Having added this solution to a Git repository there are commands available within Visual Studio to work with Git, in this case right-clicking on the solution to commit changes locally to the Git repository:


So, using Git with Visual Studio is straightforward and supported, but all that Git is providing is the version control for the project. Where and how are you tracking your requirements, capturing bugs, performing continuous integration, managing test cases and reporting on project progress? If you want distributed development wouldn’t it be nice if you could get the best of both worlds with Git for version control but retain TFS for the integrated ALM capabilities?

TFS with Git

TFS 2013 now includes Git repository support out of the box. When you create a new Team Project there is a new page in the wizard asking you to specify whether you want TFVC or Git for the version control aspect of the Team Project:


Once the project has been created the Team Explorer shows Git specific options including quick options to Clone the repository from a remote source, as well as options for local actions, but the key here is that there are Git commands alongside access to TFS features like Web Access, the Task Board and Team Rooms:


I won’t go into the step-by-step how to for using Git in TFS, as this is covered very well elsewhere, amongst others, but the Git features and the TFS features are now integrated. For example, when I commit local changes to Git in TFS, I can also associate work items (such as a user story or task):


Which when committed shows as a successful Git commit:


So, I can use the Agile planning tools in TFS:


with their underlying work items, integrated with Git as the version control solution within TFS. Note that the association between work items and commits will only show up after the local repository has been synchronised with the remote repository:


In Visual Studio this shows up in both the work item and in the Commit Details (in TFS speak the equivalent to a change set):


In web access, this can be seen via the work item or in the code view, as shown here:


This means that I can continue to use the capabilities of TFS (Agile tools, work items, build and so on), whilst selecting Git as the version control solution within TFS, and having the two areas integrated.

Is this a special “Microsoft” version of Git? No, it’s absolutely standard, meaning that you can use the tools with Visual Studio and/or your own preferred command line or other Git tools, as you wish.

TFS alongside Git

As you may have gathered from the above, you’re selecting between Git and TFVS within TFS, so you can’t have both under a single Team Project. So what about if you have a scenario where you have one or more teams within the project needing to use Git (for example iOS developers using XCode), but overall you’d like to maintain TFS as the version control “master”? This is where Git-TF comes in. Git-TF allows you to commit changes from a local Git repository to TFS, and to pull changes from TFS into the local Git, giving you a hybrid model of both Git and TFS.


I hope that this clarifies the new options around version control within TFS, and that where you might have been having a discussion about DVCS vs Centralised, or Git vs TFS, that new possibilities have been opened up.