A successful Git branching model (2010)

You can't expect to fix another bug somewhere else in the codebase if you are starting from a point where the code may not work, or features may only be partially complete.

1) Small, incremental commits tend to be way more reviewable than big "finished" blobs of work. Local/small branches prevent me from getting blocked on waiting for review, and allows me to continue working, although you don't exactly need a "branching model" for it.

2) Tests/CI are insufficient. For games, you'll want QA hammering on a release for days, weeks, or months with only the most conservative changes applied, in an effort to shake out any remaining weird heisenbugs. To do otherwise invites the specter of failing certification, delaying your release, or burning some pretty bad bugs to hundreds of thousands of physical disks. Do you, effectively, shut down the studio when you've dialed up the stability demands that much - or do you branch so work can continue?

The worst case consequences are no longer quite so bad as burning bugs into unpatchable ROMs, but they can still be pretty bad.

> The time between code being written and a bug being seen can be reduced to minutes and hours, making finding the root cause a breeze.

This is, unfortunately, merely the ideal happy path. Great when it happens, but fails to account for the worst case.

It can take weeks, months, to find the heisenbugs that slip through CI/tests/initial QA. If you have a CI/testing setup that can catch, say, a title exit(3)ing when the charm bar is opened for more than 10 seconds, but only on the main menu and without a debugger attached - without writing a test to catch that extremely specific edge case once you have the benefit of hindsight - I'm begging you to share! Just nailing down the exact repro steps took days.

When you have no relevant callstack (even when you do eventually figure out how to dump the exit(3) event), no relevant logs, the fundamental bug resides in third party code you don't have the source code to, and fully rebuilding takes hours because you're on a large C++ codebase with even larger asset building requirements - well, for me, it took me a week or two to root cause (or more accurately, get fed up to the point that I spent a day manually bisecting version history to track down a totally unrelated and innocuous looking changelist that ultimately made us hit the bug.)

In the weeks of turnaround time fixing such a bug, a sufficiently active dev branch will have acquired another. A release branch won't. Bam, branching model.

3) Plenty of codebase-wide refactoring is hard or impossible to feature-flag.

Not if you're using feature flags as an alternative to branching, nor if your feature flag is intentionally temporary. A branch is temporary, and merging the branch doesn't eliminate the point of branches, right?

For performance toggles you want to keep and use, then definitely just keep those.

> Feature toggles implemented through conditional logic seems like an anti-pattern to me. Developers make mistakes, and it's very easy to forget to wrap work around the necessary toggles

This is a valid concern generally, but in my experience doesn't detract much from the reasons to use feature toggles. In particular, the good examples you brought up (performance features & API feature toggles) you can't have without conditional logic, so there isn't any choice or alternative, right?

> It seems to me like a better pattern would be to feature-toggle on an API level

That's a good idea when the feature in question is an API feature. Are you a backend kind of person? ;) Lots of features are frontend, lots of features are full-stack. It all just depends on which feature, but generally speaking having API level feature toggles in your toolbelt is a great idea.

https://www.thoughtworks.com/insights/blog/enabling-trunk-ba...

The entire purpose of Git Flow is saving up changes to release later, e.g., saving up for a weekly release event. Don't do that! Deploy your changes as soon as they are ready, if they aren't ready don't merge them into a shared branch. If you do Continues Delivery you don't need "hotfix" branches because every changes goes out as soon as it is ready, so you don't need any of the complexity of Git Flow.

By saving up changes for a release event it means more things are getting released at once. If there is a problem after deployment it will be harder to narrow down the cause. Git Flow fosters a harmful development mentality where developers merge untested changes to the develop branch, then move on, and expect someone to test and stabilize their changes before release. With trunk-based development (https://trunkbaseddevelopment.com/) or GitHub Flow (https://guides.github.com/introduction/flow/) developers take ownership of their code, and only merge to master after they have tested it. With a good deployment pipeline they can own their code all the way to production.

Git Flow also encourages humans to think about and make up version numbers, like 15.0.5. This is a pointless waste of brain power, web apps don't need version numbers. The artifact systems (packages, containers, etc.) may need something, but it can just be an incrementing number that no on thinks about.

Git Flow wastes so much time, and makes everything it touches so complex, all to enable the harmful behavior of saving up changes for later, and enabling the pointless use of version numbers.

Trunk-based development and Continues Delivery is the default way people develop, it is how you would work if you had a one person company with one customer. It also is how the biggest web companies in the world work. It scales from smallest to largest. Just use trunk-based development. Stay away from Git Flow.

Edit: Fixed spelling of incrementing.