My team of 5 devs maintains a medium sized application consisting of 6 solutions (aka sections). At the moment, we use TFVC for source control. Each solution sits in its own Main branch.
I want to migrate to Git. My problem is whether to have 1 Git repo for all 6 solutions, or use a separate Git repo for each solution.
I'm attracted to having one single Git repo, because:
On the other hand, one single Git repo means that a change to any solution leads to a new complete rebuild of all solutions on our TeamCity CI server.
Looking for some insight from other team leads on this issue.
Even if when using git, it's commonly accepted that we should use 1 repo by project (and most of the answers or advice will tell you to do that), there is indeed the solution to put everything in the same repository, which is called the 'monorepo' strategy.
Big Internet players are doing it (not only with git) like Google, Facebook and Microsoft is (nearly) going towards it... So you could find easily some doc about pro and cons.
Ex: https://github.com/babel/babel/blob/4c371132ae7321f6d08567eab54a59049e07f246/doc/design/monorepo.md
Once you understood that one of the main problem is performance of your version control tool (but git could surely support a 5 dev team), it's more a project feeling... As it seems, you already have ideas of some advantages, and I highly advice you to test it!
Moreover, the git command to split the repository (keeping the history) if you are not satisfied is a lot easier than the one to merge repositories, so it seems to be the thing to try first.
In my team, we are going more and more towards monorepo.
My team of 5 devs maintains a medium sized application consisting of 6 solutions (aka sections).
If that is for one application, a monorepo is indeed probably the good solution.
But a problem you will have to solve is if you have dependencies between the solution managed with nuget.
Either you remove the use of nuget and you use binary dependencies (without check-in them in!) so you have to build all of them (but it will be difficult if you want to use branches).
Either you accept to make 2 commits to do an update (like you do with multiple git repositories). Could be done manually or automated with a build.
Ps: git submodules are difficult and not very advised for first time git users... so a solution based on that will be a pain :-(
On the other hand, one single Git repo means that a change to any solution leads to a new complete rebuild of all solutions on our TeamCity CI server.
Not necessarily, you could make different builds for each solution and set teamcity triggers only on their own solution folders.
Ps2: I did a longer answer that expected ;-) I hope it will help...