I have a client who uses Microsoft Team Foundation Server on site, and has been using TFVC version control for about fifteen years. They have a very large codebase with lots of discrete and interconnected Visual Studio solutions.

I've recommended moving to Git, and they're cautiously interested. It would be a large, challenging and time-consuming transition, so for the time being, "interested" means "no."

I couldn't imagine giving up Git. I wondered how hard it would be to use Git locally, but still check in needed commits to their TFS server.

There are a couple of weird things, but using Git and TFVC together is pretty easy.


I've only tested this in Visual Studio 2017, and if you're using Git you shouldn't be using any earlier VS version. You could, as long as you're willing to forego Git Visual Studio integration. Even 2015's integration doesn't work right.

Add to Source Control

This part's simple. You add the solution to the respective source controls as you normally would. With that said, I strongly recommend adding a .tfignore file, as well as a .gitignore.

You don't normally need a .tfignore because Visual Studio takes care of ignoring lots of files. But having one lets you ignore the Git folders.

The .tfignore file can be as simple as this:


I use one of the standard Visual Studio .gitignore files, then add this:


The standard .gitignore will ignore the $tf folder.

Of course, you can elect to commit the ignore files. For instance, I sometimes keep both ignore files in the Git repository.

Checking In to TFVC

The problem with checking in is that Visual Studio has a setting for Source Control Plugin, and naturally can't figure out whether to use Git or TFVC. The default behavior seems to be that it prefers Git to TFVC.

If you're a Git user, your typical flow with the addition of TFVC will be:

  1. Make a bunch of code changes in a branch, committing to your local Git repo several times.
  2. When ready to integrate your changes to master, squash the commits, switch to master, and merge.
  3. Close the solution.
  4. Open Visual Studio, but not the solution.
  5. Open Team Explorer
  6. Connect to your TFS team project
  7. I like to right-click on the solution and choose Open in Source Code Explorer. I think this isolates the solution's changes from any other changes in the team project.
  8. Open Pending Changes
  9. Be sure to scroll to the bottom and open Exclude Changes.
  10. Promote the changes as needed. If your .tfignore file is right, these will only be new and project deleted files.
  11. Comment and check in. I use the same comment that I used for the squashed Git commits.

Reopening the Solution

You'll usually get the prompt below no matter how you open the solution, and therefore have to open the solution twice. I like opening it right after check in.

  1. Open the solution, either from the Start Page, or File > Open > Recent Projects and Solutions. You'll get this message because your Source Control Plugin was changed to Visual Studio Team Services, and VS recognizes that Git source control is available in your solution.
  2. Answer Yes. The solution will close. Reopen the solution and it should open without error.

Final Thoughts

This has been a huge help to me. I'm able to code effectively using Git's power, but still support my client's environment.

This setup is also a nice way to start showing the value of Git. For example, there's likely to be very little objection to also creating a Git repo on the TFS server, and using that to synchronize long-running branches. It protects the client by ensuring my latest code is available to them, but doesn't force me to use TFVC's ponderous branching and merging.