I've started using Team Foundation Service 2012 (The cloud based offering) now that they have announced support for using Git as a source control solution.
My initial test was a single projected with a single Git repository named after the project.
Everything went well, I could clone the repo, commit push and pull from within Visual Studio 2012 and more importantly the work item association worked as well.
For the real project however, it made more sense to split the codebase across multiple Git repos in the TFS project.
There was no obstruction in doing this, the interface for Team Foundation Service supported it quite nicely....
BUT
Now I find that in Visual Studio 2012 there are a few issues and I wonder if I've either done something wrong, or if its just something that is not fully supported (yet?)
Anyone else find this and perhaps a solution (while still allowing multiple Git repos under the same TFS Project) ?
UPDATE: Found a few links such as these two
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3811952-allow-multiple-git-repositories-in-a-single-team-p
http://social.msdn.microsoft.com/Forums/vstudio/en-US/dff9c737-fbd1-4ca8-9c32-3be14eb614ba/what-is-the-best-team-project-setup-for-using-git-with-tfs
So at least one other person has bumped into it.
The multiple repo's work fine if you use Git to push remotely to the correct repo URL, it only breaks down if you use the Visual Studio 2012 integration in terms of work item association and cloning the repo.
With Git, using multiple repositories is the only way to work efficiently. This enables each team to work independently, and do their work faster. You can also make sure that developers only have access to the repositories they need access to (thus making Git more secure.)
Git in Visual Studio, Azure DevOps Services, and TFS is standard Git. You can use Visual Studio with third-party Git services, and you can also use third-party Git clients with TFS.
Having multiple repositories makes it easy to give access to subsets of repositories on a “need to code” basis. I set up Continuous Deployment for my projects. It's much easier to let each repository have it's own process for being deployed.
This is a limitation of the Visual Studio Tools for Git extension that is available for Visual Studio 2012.
This problem does not exist in the Git tools that come as part of Visual Studio 2013.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With