HN Explorer

Ask HN: Branching strategies for monorepos, what is your approach?

2 points by floppydisc ↗ HN
Having stumbled upon Git Flow and the wonders of monorepos, I do wonder how to best implement a Git Flow like branching strategy for the monorepo. Branching fundamentally seems to fit better for polyrepos or repos with a single project. Have you come up with a branching strategy for monorepos and if so, what is it?

4 comments

[ 0.21 ms ] story [ 20.1 ms ] thread
jstx1
Have short-lived branches for whatever change you're making, merge into main, repeat.

Is there a problem with this? Seems too obvious to even call it a strategy.

matart
This is how I have done it at multiple companies. Anything else has always felt too complicated.
onetimePost
In my experience the traditional branching strategies work for monorepos for continuous integration.

For continuous deployment the circumstance is a little different since you may not want continuously deploy every app if there are changes that don't affect all apps.

For example, supposing a monorepo that contains source for three separate apps A, B, C. If a branch contains changes for app A only, when merged, you may not want to redeploy all apps, but only affected apps. In this case you may want to organize a conditional deployment model instead of a continuous model. If you CICD system is tied to branches, and branch events, you may need to organize a separate release branch modeling along side the preexisting integration model.