Menu
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.
846
If the project you are on is a single project with lots of parts it is less important to keep things separate. It might still be easier if each module were separate. But if you have lots of small or medium projects that use various modules then it is very useful to have separate repos.
Mono-repo favors consistency, whereas multi-repo focuses on decoupling. While in a mono-repo, the entire team can see changes done by one person, multi-repo creates a separate repo for each team, who have access to only the required services.
We recommend repositories remain small, ideally less than 1 GB, and less than 5 GB is strongly recommended. Smaller repositories are faster to clone and easier to work with and maintain.
What Is Multi-Repo? The multi-repo approach uses several repositories to host the multiple libraries or services of a project developed by a company. At its most extreme, it'll host every minimum set of reusable code or standalone functionality (such as a microservice) under its repository.
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...
111
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
