Trunk Based Development

I still have nightmares from my first dev gig. We used SVN, which even in 2015 was prehistoric technology. The server was some awful rustbucket that couldn't sustain 100Mbit. Yes, it couldn't saturate basic 100megabit Ethernet. Everyone had to have big drives in their workstations to maintain multiple local trees. You just couldn't work otherwise.

But probably the worst part was that when I started it was a loose organization where anyone could sneakily merge something into trunk. That changed quickly.

All work was done against a develop branch, and every two weeks, the admin would DELETE THE TRUNK and recreate it from a COPY of develop.

Every two weeks, we lost all history and context for changes in any given release. This was an effort to stop bugs coming back in merge regressions.

Can you guess how well this worked out for them?

I've rarely seen the first description of it where people actually commit directly to main. Except in very early stage projects. But it does always feel the fastest if you only review code "on-demand" in PRs/MRs instead of enforcing it for every change.

I think in a team with good ownership, enforcing formal reviews slows down a lot. But of course in a larger code base where no single engineer can understand all the effects a change might have, having a bit of knowledge sharing and 4 eyes enforced is often the better approach than yolo-ing it.

Then again I did build an SQL review tool for database access because I felt like "yolo-ing" production access was also not the way it should be. It's an interesting slider between full autonomy and strict review processes where each team needs to find their sweet spot: https://github.com/kviklet/kviklet/

Working without branches, except for releases, is the most effective way of working, using rebase instead of merge to get a single line of commits. Even release branches can be avoided with continuous deployment.

stacked PRs. stacked PRs!

Seriously wish the stacked PR workflow would gain more traction outside of FAANG. Apart from the (somewhat pricey) Graphite offering, there's no standard UI for managing stacked PRs in the wild.

I worked in a team of four between 2017 and 2020 this way. I really enjoyed it. After that I joined a company that worked with PRs. Felt like such a waste of time.

trunk based is the way to go, especially for small teams building web / backend services

especially combined with monorepo

amount of time people spend updating dependencies between internal services and libraries in a pursuit of semver for now reason is just absurd

The thing missing with a lot of these branch management posts is release management… because it’s lovely to live in an ideal happy-path world, but what happens when main is tagged for release, only some customers update, main moves of with multiple breaking changes, and only then do some customers require fixes to their releases (who could all be on different i.e even older tags)?

Do you take their tagged release, fix it there, and then send them that branch release with the fix, or do you send them a fix on current main - you know, the main that is now a million releases ahead with multiple breaking changes? And what about all the intermediate release tags? Do you fix each one there too if they have the problem, or do you only update when customers on those releases start having that issue too?

And if you fix to their old tagged release which is incompatible from main, does this mean you have to do this fix twice i.e on their tagged release and also fix it for main? But what if this fix affects other people who are all on different branches too? Now… times this by 20 different customers all running different hardware and different branches with different problems :(

Maybe my comments are off topic, and don’t get me wrong - I prefer “trunk is releasable” motto, but I think maybe as an industry we should all come up with an Acid Test (like the only CSS Acid Tests) so we can through all these branching strategies into the ring

Trunk-based becomes even more critical when AI agents are writing code. Long-lived branches create merge hell when both humans and agents are committing. We've found keeping everything on trunk with feature flags is the only sane way to coordinate human + AI contributions.