Re:A note of reflection after 10 years of “A successful Git ...
by geofft on Thursday March 05, 2020 @11:28PM
(#22500998)
Yes, in those situations you will need additional branches beyond just master (and short-lived/personal feature branches). But,
1. You can implement the necessary branching with much less complexity than git-flow. Just have master, plus possibly some stable development branches created when you need it. Tag v1.0.0 off master, then make the v1.x branch and tag v1.0.1 on it. Or branch v13.x off master and tag v13.0.0 once it's stable. No "develop" branch, no long-running feature branches, nothing.
2. Importantly, you can implement the necessary branching when you need it. If you never run into these situations, you can keep having just a single master branch and not worry about it. You do not need to future-proof yourself for fear that you might run into a complicated situation. If you do, then you can make release branches at that point.
You don't need a separate "develop" / "master" branch to cover up weakness es in your CI. If your CI is good enough that you can automatically merge "develop" into "master" when tests pass, it's good enough that you can actually implement the Not Rocket Science Rule and automatically merge everything into master when tests pass. If it's not good enough, then just keep track of the last-known good commit on master, and fix build/test failures on master urgently, don't shove them off onto another branch so you can ignore then. The industry standard is the idea that "who broke the build" is a well-defined question - but it means the right step is to fix the build.
1. You can implement the necessary branching with much less complexity than git-flow. Just have master, plus possibly some stable development branches created when you need it. Tag v1.0.0 off master, then make the v1.x branch and tag v1.0.1 on it. Or branch v13.x off master and tag v13.0.0 once it's stable. No "develop" branch, no long-running feature branches, nothing.
2. Importantly, you can implement the necessary branching when you need it. If you never run into these situations, you can keep having just a single master branch and not worry about it. You do not need to future-proof yourself for fear that you might run into a complicated situation. If you do, then you can make release branches at that point.
You don't need a separate "develop" / "master" branch to cover up weakness es in your CI. If your CI is good enough that you can automatically merge "develop" into "master" when tests pass, it's good enough that you can actually implement the Not Rocket Science Rule and automatically merge everything into master when tests pass. If it's not good enough, then just keep track of the last-known good commit on master, and fix build/test failures on master urgently, don't shove them off onto another branch so you can ignore then. The industry standard is the idea that "who broke the build" is a well-defined question - but it means the right step is to fix the build.