7

We recently decided to move from TFVC to Git and I'm trying to find the best way to design our new Git architecture.

Our code is made of independent but tightly coupled modules, let's look at the following projects:

  • CommonLib1

  • CommonLib2

  • ApplicationA (uses CommonLib1)

  • ApplicationB (uses CommonLib1 & CommonLib2)

Although CommonLib1/CommonLib2 are completely independent, almost every new feature for ApplicationA/ApplicationB would require modifying CommonLib1/CommonLib2.

Moreover, when adding new features we would like to create a single branch that would span between all our projects.

As far as I understand, I'm left with 2 main options:

  1. Create a repo for each project, and add CommonLib1/CommonLib2 as subtrees in ApplicationA/ApplicationB.

  2. Create a single Monorepo for all the projects.

What would be the best Git practice for my situation?

Michael
  • 796
  • 11
  • 27
  • Google has had success with the giant monorepo. I would suggest starting there and trying to break up the tightly coupled projects. – jaredready Feb 26 '17 at 18:33
  • I'm sure it will work, but I'm searching for the best practice .. I prefer to start from the beginning in the correct way – Michael Feb 26 '17 at 19:39
  • Is "monorepo" a real thing now? I see a number of hits on Google (https://www.google.com/#q=monorepo) but they're all just talking about "dump a bunch of crap into one big repository", which is not really a *thing*. The tag exists now on StackOverflow but has literally nothing for its tag-specific information: http://stackoverflow.com/tags/monorepo/info – torek Feb 26 '17 at 22:07
  • Possible duplicate of [Git using subtree or submodule to manage external resources](http://stackoverflow.com/questions/12668711/git-using-subtree-or-submodule-to-manage-external-resources) – Pockets Feb 26 '17 at 23:07
  • 2
    Also you should *not* do something just because Google does something - they've literally forked the DVCS software they use and rolled their own versions **because publicly available tools are unsuitable for their workflow**. – Pockets Feb 26 '17 at 23:09

1 Answers1

3

Since CommonLib1/CommonLib2 are closely related with ApplicationA/ApplicationB, so you’d better use option2 (create a single Monorepo for all projects). The branches structure can be as below:

  • Lib1 branch: manage/develop/update CommonLib1 in this branch. When it’s updated, you can merge it in appA and appB branches.

  • Lib2 branch: manage/develop/update CommonLib2 in this branch. When it’s updated, you can merge it in appB branch.

  • appA branch: manage/develop ApplicationA project.

  • appB branch: manage/develop ApplicationB project.

Marina Liu
  • 36,876
  • 5
  • 61
  • 74