A successful Git branching model (2010)
Upvoted for the retraction.<p>Personal opinions on best practices:<p>- If you have multiple components to an application, whether frontend&#x2F;backend or microservices, put them all in the same repository by default. It is so easy to split them apart again after your team grows to the point where it matters, but before that point you will need to carefully coordinate merging PRs to multiple repos, and sometimes rolling them back, and it is so easy with a small application monorepo. You can just store git’s “tree hashes” in s3 and check if they changed when deciding whether to build and deploy, it&#x27;s not hard.<p>- If you&#x27;re versioning, a version.txt file at the root of the versioned content is your friend. Have a {subproject_name}-v1.6 branch, you tag commits on that branch v1.6.3-rc1, rc2, ... automatically with CI&#x2F;CD, until you tag one RC as a release when you release it.<p>- Everyone merges into main, you cherrypick from main out to those other branches. This keeps the graph clean. When you cut v1.6 you decide whether your next project on main is v2.0 or v1.7.<p>- Feature toggles are your friend, see Rod Hilton’s Three-Flow[1]. Just clean them up when you release!<p>- with about a day&#x27;s involvement in CI&#x2F;CD, the `main` branch can have a `k8s&#x2F;` folder with subfolders for each of your deployment environments. You want to deploy something to prod, just update a version number in `k8s&#x2F;prod` and merge to `main`. This is even a little simpler than Three-Flow and you can very precisely answer when something was shipped.<p>- folders `rfc&#x2F;` and `docs&#x2F;` and `issues&#x2F;` at the root level would be amazing but I can&#x27;t get any company to actually do them. One stop shopping! Why not? Once `main` is authoritatively central, it becomes a great place for these things, just the same as you use it for `k8s&#x2F;prod` and `k8s&#x2F;dev`.<p>- The underlying point of all of this is to make sure that everybody merges their code every day. If that would break something, put the breakage behind a feature toggle. If it&#x27;s a config file that doesn&#x27;t have feature toggles, run the C preprocessor on it or invest in Dhall or some other hack. Do whatever you can so that there is one big conversation happening, and everybody is collaborating. The worst is when you have these huge merge conflicts, the second worst is when you have been doing a lot of work and someone else sweeps it all away before you merge, &quot;oh I didn&#x27;t see you working on that so I solved it in this inferior hacky way.&quot;<p>1. <a href="https:&#x2F;&#x2F;www.rodhilton.com&#x2F;2017&#x2F;04&#x2F;09&#x2F;a-different-branching-strategy&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.rodhilton.com&#x2F;2017&#x2F;04&#x2F;09&#x2F;a-different-branching-s...</a>