Hosting Git Repositories in TFS

One of the great features of Git as a version control system is that there's no vendor lock-in: you can create a new Git repository on your local computer and push it to any Git server to collaborate with your team. This allows you to choose whatever Git hosting provider you want to use: it could be Team Foundation Server, GitHub, Codeplex, or even setting up your own Git server that you access over a network file share. We've been busy adding unique features to Team Foundation Server so that it's a compelling place to host your Git repositories.

Application Lifecycle Management

One of the original goals behind Team Foundation Server was to build an integrated environment for all the assets of your development team: requirements, source control, bugs, builds, tests; all that stuff. (We call this "Application Lifecycle Management".) We want to provide this integration, of course, whether you use Team Foundation Version Control, our centralized version control system, or Git.

That means that you can link a bug directly to a Git commit, and when you push, you'll see the link between your commit and your work item:

Plus, you can easily set up a continuous integration build, so when you push your commit, it will kick off a continuous integration build.

This all comes when you install Team Foundation Server, or built-in to [[Visual Studio Online]]; you don't need to install any other tools or set up any integration points with other services.

Backups

Having your Git server integrated into Team Foundation Server means that you can take advantage of the management features of TFS - in particular, the backup and restore tools. This ensures that your backup represents a coherent state of all your development artifacts.

Without a transactional backup across all of your systems, you could end up with a backup of your source control from early Saturday morning and a backup of your work items from Friday night, a few hours before. This means that you could end up creating some bug on Saturday morning, pushing a commit to fix it and (of course) associating the commit with the work item.

If you didn't have a transactional backup, you'd end up with a commit pointing to a nonexistent work item. Worse, if your work item tracking system uses monotonically increasing IDs (and most do, of course) then you'd end up with your commit pointing to a completely unrelated work item. Team Foundation Server provides integration in these tools, even when you restore the data.

Finer-grained permissions

Due to the format of a Git repository, one cannot set permissions only on a single file or folder, like you can with Team Foundation Version Control. Instead, you generally set the read permissions for a repository and the write permissions for a repository.

Team Foundation Server also lets you set the permissions for a specific branch, to control who can update a branch pointer:

In addition, TFS lets you control who can force push to a branch, giving that very special ability only to administrators and the branch creator, by default. This can preclude many of the problems that go along with force pushing public branches.

Additional Auditing

Most Git hosting providers make it pretty easy to see who authored a change: who actually made the changes. And most Git hosting providers make it pretty easy to see who committed a change into the repository: who actually placed those changes into the repository. In some workflows, where very few people commit to a repository and other contributors interact through a different mechanism, like over a mailing list, these two points of data may be all you need for auditing.

In many workflows, though, many people on a team are allowed to push their changes into the repository. In this sort of workflow, if I get disgruntled and decide to act maliciously, I could impersonate one of my coworkers. Heck, I could even impersonate my boss, and write a commit that appears to be from him:

Thankfully, Team Foundation Server also stores the "push log" so that you can see not only who purported to write the change and put it into the repository, but who actually authenticated to upload the change:

(Of course, this doesn't replace code reviews, but it does provide an additional safe guard.)

Some of these features are available with other Git hosting providers; especially if you set up your own Git server. But Team Foundation Server provides them quickly and easily, so you can have these handy features out-of-the-box, without having to spend a lot of time configuring them.