Git – Team switching from TFS Source Control to TFS with Git, not sure how to handle complex project structure

The advantages git has come from tossing out a lot of old assumptions about what a VCS should do. The disadvantages git has come from not being able to leverage prior experience and not being able to do things the way you are used to.

If you are going to switch from something else to git, try to start tabula-rasa (though it is impossible to truly do in practice). Evaluate it based on what it does and how well it does it, not on how it does it compared to how you are used to doing it. It's not that you expect too much, it's that your expectations are orthogonal to what git provides. If you're married to GUI operation, you'll be disappointed. Git does have gui tools available, but they don't add much. That's not a failure to provide them so much as there isn't that much that a gui can add. GitK does help, not in day-to-day operations, but rather in visualizing the branch structure and examining or searching history.

Here's a goofy analogy for what I mean by "orthogonal". One of the things you can do with a newspaper is wrap fish in it, or use it to line a birdcage. But those are not essential to the function of a newspaper, those are incidental features of the form it comes in. Expecting git to "check in files", or "allow you to select projects", or provide a "connect to..." is kind of like expecting to be able to wrap fish or line your birdcage with a newspaper's website.

Stick with one TFS Team Project, having multiple becomes a pain when trying to upgrade and has some limitations when it comes to cross team project work items. Instead you should be making heavy use of Areas and Iterations.

Split your VS Solution into multiple solutions, one per major application. This will speed up local builds a lot, as well as the build server.

TFS2012 has a new concept called Teams, create a team per application and set default iterations and backlogs for each. This way you can manage the backlog for each, or view the root team to see a rolled up backlog. Then you can manage sprints either at an application level, or overall depending on what suits you.

Create NuGet packages for all 3rd party referenced libraries that don't already have one. Store them in a private repository (windows shared folder) and enable the package restore feature for NuGet by right clicking every solution and enabling it (also allow package restore to download packages in vs settings).

If you have any shared internal libraries then create NuGet packages for them also, and create a vs solution just containing that library. Add a post build command to create the nuget package, or extend your tfs build template to do it (there's a number of templates out there that already do this).