[thaumaturgy]

Nice to see this getting some treatment. It's been my preferred source control strategy at several places now -- both small and large, though nothing so large as Facebook.

It has its limitations, but for the the 90+% of places that aren't operating at Facebook scale, it's probably the right choice. It doesn't eliminate merge hell, but it does localize it, making it a lot easier to resolve conflicts without accidentally undoing somebody else's work.

It's especially well-suited for any projects that are in constant-iteration mode, where there's a steady stream of bugfixes and new developments getting deployed daily (or even multiple times a day).

You can even manage longer-lived branches after a fashion: the cleanest pattern seems to be to capture your changes into a patch, revert your branch to the commit immediately before your changes, merge/rebase main, then apply your patch on top. This is bad and lame because it rewrites history and requires a force push to get it into the remote, but it's also nice because it keeps your changes at the tip of the branch and makes review a bit easier in e.g. GitLab.

Every small shop I've worked with that has tried to use more complex branching models eventually hoses the repo and ends up burning a lot of dev hours one day trying to make sense of a git log that looks like a diagram of network sorting.

[striking]

A lot of the rebase/merge hell I've seen has been more or less resolved with the introduction of a merge queue. Granted, there are other issues that crop up (notably, flaky tests go from being an annoyance to life-threatening) but at least bigger changes don't get blocked and stay blocked.

[reissbaker]

FWIW, Facebook also uses trunk-based development, so it works at that scale too!