21

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:

  • Reduced complexity for the team.
  • One commit can have related changes in several solutions (such as moving code from one solution to another).

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.

Edward Thomson
  • 74,857
  • 14
  • 158
  • 187
user1147862
  • 4,096
  • 8
  • 36
  • 53

5 Answers5

19

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...

Philippe
  • 28,207
  • 6
  • 54
  • 78
  • 1
    Did you read your answer after writing? It contains an amazing number of mistakes on all levels from typos through to massive thinkos. I was going to edit but I don't think a single sentence would remain. – TamaMcGlinn Jul 20 '20 at 13:48
  • 2
    @TamaMcGlinn Did you read your comment after writing? It is very condescending. Everyone is not an English native speaker (but I'm pleased you think I am!) and that should not prevent to give his point of view....But I would be pleased if you give your point of view in a comment or better in a new answer! – Philippe Jul 20 '20 at 15:30
  • I'm sorry for hurting your feelings. I tried to edit just the grammar and spelling but need to understand what it means first. What did you mean 'admitted' in 'it's currently admitted to use 1 repo?' Did you mean permitted, as in allowed? Or 'possible' ? Or 'recommended' ? To admit is to say something true but that you prefer not to say, as in 'I admit that my comment was hurtful'. – TamaMcGlinn Aug 12 '20 at 08:42
4

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.

jgmjgm
  • 4,240
  • 1
  • 25
  • 18
  • Agree 99%. One nit: I have used Git with very large code bases without problems. Much to my surprise at the time. The trick is to _never_, *ever* commit any binaries, dependencies or generated artifacts. Even if the code contains these items, you can clean up the source tree and limit the depth of the versions you pull with Git. But, even with lots of crud checked in (old code bases, many developers, no good dependency managers for C/C++, it happens ...), a 1GB repo is ok after the initial clone. – Charlie Reitzel Apr 20 '22 at 19:09
2

keep the methodology as it currently is, with one repo per solution. If you need to, configure TeamCity to build only based on changes in certain repos. I know jenkins can do this.

Larry G. Wapnitsky
  • 1,216
  • 2
  • 16
  • 35
2

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.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
  • 2
    If your team does not have a lot of experience with submodules then I would advise against this approach. Submodules are cool on paper but in practice they can really cause a mess. – zypherman Apr 26 '17 at 14:41
  • 2
    "If you don't have experience with them, don't gain experience with them"? If you have a concrete issue with them I'd be interested to hear about it, but this just sounds like the kind of FUD people throw around if they haven't - and don't want to - learn how to properly use a feature. – Mark Adelsberger Apr 26 '17 at 15:01
  • 1
    @Mark Adelsberger I don't know the submodule concept but does that provide the monorepo advantages ? Mainly : commit consistency : a single commit with related changes on any subproject and no the hell of merge between the feature branches and the main/default branch for each repository. I fast skimmed the official doc. It didn't give me the feeling that it provides these powerful advantages of the mono-repository layout. – davidxxx Jul 04 '19 at 14:20
  • @davidxxx - Since I'm strongly anti-monorepo, I'm probably the wrong person to ask about monorepo "advantages". – Mark Adelsberger Jul 05 '19 at 21:23
  • @davidxxx yes; a repository that contains submodules is able to atomically switch from one set of commits (of the submodules) to another, so that related changes in different repositories are kept together. – TamaMcGlinn Jul 20 '20 at 13:47
1

I know this is an old question but just wanted to throw the Git OPS, Infrastructure as Code perspective into the mix.

When you are using highly parameterised and templated IaC files that rely on convention-based naming and substitution, it makes much more sense to have one Git repo per feature.

In a mono-repo, you would need a fair bit of custom IaC plumbing that might be less standardised or reusable.

Wim
  • 11,998
  • 1
  • 34
  • 57