29

I'm using Git Flow with multiple projects, each with their own repository, successfully.

I'm looking to merge these repositories into a single monorepo. The main reason being shared dependent projects across multiple projects, which, currently means we need to commit fixes across multiple repositories (see: cross-project changes in the link above).

Facebook and Google seem to successfully use this model (see: this fb talk, and this google talk).

How can I keep using something similar to Git Flow while utilizing a single repository for multiple projects?

While useful, the talks I've linked to don't go into details like branching and tagging, and how they organize different project releases from a single trunk/master.

I'm not married to Git Flow. I'm looking for how to structure releases in a monorepo.

user1431368
  • 585
  • 8
  • 15
  • 2
    Seriously, don't. Just use submodules if you need to tie specific versions. – o11c Jul 31 '15 at 19:58
  • 4
    I honestly wouldn't use a monorepo if you're working with Git. The reasons Google and Facebook use it are a combination of "it's always been done that way" (Google), "we have a lot of Perforce users" (Google), and "it was easier to migrate our SVN repo" (Facebook). Of course, in typical Google/Facebook fashion, they give lengthy talks about the supposed benefits in order to justify their decisions. But to be honest, monorepos don't fit with the Git model and tools that are designed to work with Git. – mipadi Jul 31 '15 at 20:31
  • Are your releases sync'd across all the projects? Meaning do the have the same version number and get released together? If not then I imagine the number of branches might get out of control. – Jose Martinez Aug 03 '15 at 12:50
  • 5
    Submodules are what we use now, but they don't make cross-project changes easy. A and B both depend on C, a change in C requires commits to C, then A and B. @JoseMartinez Right now, A and B (in this example) release at different times with different versions; yet they both depend on C. You're right that git-flow branches would be multiplied by # of subprojects, which gets unwieldy. I am still wanting to try this monorepo just to see if we can get something better than what we have now; if not, we'll continue to use submodules. Still looking for suggestions, thanks guys! – user1431368 Aug 06 '15 at 19:05
  • I agree its worth a shot. – Jose Martinez Aug 06 '15 at 19:34
  • There was one other issue that came to mind... btw I am at similar crossroads over here.... big checkouts. When I only need project B to be cloned, I have to clone the whole giant monorepo with A, B, and C. – Jose Martinez Aug 06 '15 at 19:49
  • That's an issue with monorepo's for sure, which you would solve by moving to multiple repo's. For me, I'm willing to make that trade-off to explore greater productivity after checkout. Facebook solves this with a monorepo by moving to Mercurial, and implementing extensions that allow for sparse checkout. Check out their talk I linked above. Git has shallow clones, which doesn't directly solve your problem but may help. – user1431368 Aug 06 '15 at 20:38
  • As you may have noticed both FB and Google moved away from Git to Mercurial when they implemented the Monorepo. And even more, they are using a FB enhanced version of Mercurial. I don't know if the main stream Mercurial has implemented the FB patches or if mainstream Mercurial can be used effectively on a Monorepo. – Peter van der Does Nov 03 '15 at 19:13
  • @Peter van der Does: IIRC, FB initially experimented with Git, but moved to Mercurial later _only_ because they felt that it would be easier to extend its Python codebase, rather than having to deal with Git's source code written in C. –  Dec 25 '16 at 21:41
  • @user1431368 have you found a solution for this problem ? I'm in the same situation as you. – Hicham Aug 06 '18 at 09:15

1 Answers1

2

What about using a branch for each project, and using child branches as git-flow branches with proper namespacing? For example; there's a branch named project#1 for a project, which is analogous to master, and has child branches named project#1-develop, project#1-hotfix#11, and so on. Also you can have the single master branch into which you merge the project branches at releases.

  • 4
    despite the fact that this question is probably not suited for SO per its guidelines, I'm interested to see how this unfolds. We are headed towards monorepo, and I've come up with this same thought on how to make it work with git and gitflow. Currently we have PR hell, and our team is small. I dread what will happen as the team grows. – Nick Jan 08 '18 at 20:01
  • I am also interested. When you create a release on gitflow you effectively prevent any other releases until you close it. On a single project repo this is fine, but i can't see how this could work on a mono. Unless you can create a feature on just one app/lib instead of entre repo? – batman567 May 16 '22 at 07:14
  • This might seem as a good solution at first, but, creating branches for each project is nearly the same as having them in separated repositories. You can think that you are in the same repo, and indeed at low level you are, but semantically not. This means that if you need to share code between project's branches things can become very confusing. – vanderdill Dec 21 '22 at 00:54