[MaulingMonkey]

Here's the caveats I have with that, although I do trend towards only having a master central branch whenever possible:

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.

[sillysaurus3]

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.

Eh.. Game studios aren't generally still in the dark ages, are they? Physical disks went the way of the dodo. (Every game now basically requires updates on first use, right? So even if consumers get a disc[o ball], they won't really be affected by a bug burned to it.)

But yes, solid points.

[MaulingMonkey]

> Eh.. Game studios aren't generally still in the dark ages, are they? Physical disks went the way of the dodo.

I wish! Turns out enough of the world still has terrible enough internet for sneakernet to still have it's advantages. It's not the game studios that are in the dark ages ;)

> Every game now basically requires updates on first use, right?

Sadly. It's a pretty terrible experience. Ideally it's a small optional patch, or maybe only required for online play - but your ability to do that depends in part on how bad the bugs are without it. The ability to do day one patches doesn't translate into a rubber stamp either - it's easier to get a waiver on a few heisenbugs than a truckload. And this is in the "okay okay, we'll backpedal on requiring our console to be always online" world of console dev - I imagine mandatory day 1 patches are even worse on handhelds.

And if you don't want that day 1 patch to introduce more bugs than it fixes (souring your launch, reviews, and ultimately sales) - or a release delay messing up your marketing plans (to potentially similar effect and/or extra costs) - you still need as stable a build as you can get by some hard cutoff X, so you're back to having a release branch, freezing master, or some combination thereof.