3 ms·
Ask HN: Branching strategies for monorepos, what is your approach?
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?
- jstx1 3y agoHave 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 3y agoThis is how I have done it at multiple companies. Anything else has always felt too complicated.
- shoo 3y agohttps://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ https://yosefk.com/blog/dont-ask-if-a-monorepo-is-good-for-you-ask-if-youre-good-enough-for-a-monorepo.html https://yosefk.com/blog/dont-ask-if-a-monorepo-is-good-for-y...
- onetimePost 3y agoIn 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.