One big Git repo or multiple smaller ones

I would keep each project in its own repo and let the build server interact with them individually. You can still simplify things for developers and facilitate coordination of changes across repos by creating a single repo that includes each of the individual project repos as a submodule. So developers check out the big repo (which, via submodule references, will grab the project repos) and the build server just pulls the project repos.

Even if when using git, it's currently admitted to 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...

For open source, where you want to expose VCS access to the world at large then you should have a repository per project. Many conventions for open source projects have traditionally used a repository per package a project produces but this is changing as established conventions and tooling around packaging are improving to better support multi-tenant repositories.

For internal work a single repository (or a few big repositories) is far superior. It's very hard otherwise to do things like ensure consistency between codebases that need to interact or share resources. In the real world, in every situation with many repositories I have found myself having problems with the additional overhead and synchronisation problems incurred by having to work across additional repositories unnecessarily.

There are caveats. For things that have nothing to do with each other, they can happily be in separate repositories. Git also has certain deficiencies with mono-repos. You'll see this if you compare it with SVN where monorepo works very well (externals, no need to pull entire repo, can get a specific folder, etc). You can get around some of these such as with the use of symlinks.