Sometime last month, Microsoft released its Visual Studio Tools for Git. The tool is an extension for Visual Studio that allows source control integration with Git. It enables you to integrate Visual Studio with local Git repositories and provides tools to work with remote repositories as well.
I’ve recently become a big fan of Git and have begun using it to see how I can enhance my personal development workflow and see what else I can get out of it. So after hearing about the Git extension I was eager to try it out.
I had an existing project of some code samples with a git repo on my local machine. This project was also on my clients on-premises TFS 2010 server. After installing the extension, the project was immediately recognized as a Git team project and it appeared that all was well. I quickly switched to another task with the intent of orienting my self to the extension later. When I went to show the code samples from the project, I noticed that all the files were marked as read-only and VS kept prompting me to save the files with another name after making changes. Thinking the source code was still being managed by TFS, I checked the Source Control -> Environment -> Checked-in items -> Editing settings, to ensure it was set to ‘Check out automatically’. To my surprise, the Environment and Visual Studio TFS settings were missing!? I realized then, there was more to it and continued with my demo by un-checking the read-only property for each file, to save the changes before running the examples.
When I had some time to look into what had happened, I noticed that the project had been un-bound from TFS source control. After looking thru the Q&A on the extension download site I found out that you can’t create a project on an on-premises TFS server that is a git repository. Apparently, a project can only be a traditional Team Foundation Version Control (TFSVC) team project, or a Git team project — you can’t have both. Which makes sense, since distributed version control is so different then centralized version control. Right now, Git team projects can only be created on Visual Studio’s cloud service, tfs.visualstudio.com. The next major release of on-premises TFS will include support for Git team projects, but they are not available in TFS 2005-2012.
This is somewhat of a disappointment as I was hoping to maintain a local git repo that I could manage locally and/or remotely, while having it managed as a traditional team project simultaneously; didn’t necessarily want a Git team project.
To fix it, I disabled the extension and then changed the source control using the Change Source Control command ‘Bind’ function. This allows a user to reestablish a source control link between a solution/project and the version store. Previous attempts with the extension enabled resulted in an error.

Start by disabling the extension and then restarting Visual Studio.

Open the project that has the git repo. You will be asked if you want to permanently remove the source control bindings from the project. Selecting either ‘Yes’ or ‘No’ does not seem to matter.

After the solution opens, you should notice that the solution is no longer under source control in Solution Explorer and Team Explorer should indicate that TFS is not the current source control provider. Also note that the Source Control menu under the File is missing. To enable the Change Source Control command you will first need to set TFS as the source control provider by either clicking on ‘Change Plug-in’ in Team Explorer or going to Tools -> Options -> Source Control settings.

Select Visual Studio TFS as the source control provider.

You should now see the Source Control option under the File menu. Click ‘Change Source Control’

The project should be unbound. Select each Solution/Project and click Bind. Your project should now be connected.

You may be prompted by Visual Studio to check out your project from TFS.

Your files should now show that they are under source control in Solution Explorer.
For now, I’ll continue using Git for Windows to manage my local repos and push/pull from GitHub. And if the project is a traditional team project on TFS, then I’ll commit my changes (on TFS) and be done with it.