Trunk Based Development • Hacker News Board

Re: Trunk Based Development

#11

Post by reverius42 » Sat, Feb 21, 2026, 9:36 AM UTC

dxdm wrote: post #4

jascha_eng wrote: post #2

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…

As I understand it, trunk based development does not call for committing directly to main. It says to avoid long-lived branches for releases, whole features, etc. There's nothing wrong with small, short-lived branches that can be quickly reviewed and merged into main. That being said, I've been in a small team where the blessed style was to commit directly to main and do reviews "on demand". It quickly gets features…

> "Scaled Trunk-Based Development"

> There's nothing wrong with small, short-lived branches that can be quickly reviewed and merged into main.

I would have called this "branch based development", personally.

Re: Trunk Based Development

#12

Post by roggenilsson » Sat, Feb 21, 2026, 9:37 AM UTC

jascha_eng wrote: post #2

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…

In my previous job we worked like this. We had one dev branch that everyone pushed directly to and the dev branch was eventually branched to an RC branch which in turn was merged to master once the release was complete.

The team was small, around 6 people, and the codebase was maybe medium sized (~500k LOC). There was no formal review process, instead it was up to each team member to ensure the quality of their own and others code. In practice I would read through all commits that came in the previous day while having my morning coffee. If there was some egregious I would talk to whoever made to commit to make discuss if something should change, but this was fairly rare.

Formal PR reviews were only ever really used for new members or for bigger/sketchy changes where someone wanted more eyes on it.

Because I ended up reading most commits, I ended up knowing how pretty much the entire codebase worked. It takes a while for this to develop, but the more you do it the better you get at it, especially in the context of a single codebase.

Re: Trunk Based Development

#13

Post by KronisLV » Sat, Feb 21, 2026, 9:44 AM UTC

reverius42 wrote: post #11

dxdm wrote: post #4

Earlier quoted context omitted.

As I understand it, trunk based development does not call for committing directly to main. It says to avoid long-lived branches for releases, whole features, etc. There's nothing wrong with small, short-lived branches that can be quickly reviewed and merged into main. That being said, I've been in a small team where the blessed style was to commit directly to main and do reviews "on demand". It quickly gets features…

> "Scaled Trunk-Based Development" > There's nothing wrong with small, short-lived branches that can be quickly reviewed and merged into main. I would have called this "branch based development", personally.

Hmm, branches you say? Branches that contain features?

https://www.atlassian.com/git/tutorials/comparing-workflows/...

But yeah, that’s what people generally settled on, naming wise.

Re: Trunk Based Development

#14

Post by locknitpicker » Sat, Feb 21, 2026, 9:45 AM UTC

fjfaase wrote: post #9

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.

> 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.

I think you're confusing workflows with commit history.

You can work with feature branches all you want, rebase them as you feel like it, and then do squash merges to main.

The likes of GitHub even have a button for this.

Re: Trunk Based Development

#15

Post by reywilliams » Sat, Feb 21, 2026, 9:52 AM UTC

swiftcoder wrote: post #5

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.

GitHub[1] is working through this now, hopefully it leads to more adoption.

[1]: https://x.com/jaredpalmer/status/2019817235163074881?s=20

Re: Trunk Based Development

#16

Post by KronisLV » Sat, Feb 21, 2026, 9:52 AM UTC

jascha_eng wrote: post #6

dxdm wrote: post #4

Earlier quoted context omitted.

As I understand it, trunk based development does not call for committing directly to main. It says to avoid long-lived branches for releases, whole features, etc. There's nothing wrong with small, short-lived branches that can be quickly reviewed and merged into main. That being said, I've been in a small team where the blessed style was to commit directly to main and do reviews "on demand". It quickly gets features…

> well-aligned developers I think this is very key, if the development style and the direction of the project is clear, much less review and alignment is necessary. And also > avoid keeping branches open for more than a day Big +1 on that, fast reviews are extremely key. Most teams I have seen often took days or even weeks to merge branches though, often because you end up waiting too long for reviews in the first pl…

> However usually code is easy to change, so defaulting to "just merge it" and creating followup tasks is often the cheaper approach than infinite review cycles.

I wish this was the "default" mindset everywhere, especially in those cases where you have that one colleague that loves to nitpick everything and doesn't see an issue with holding up both releases and wasting your time over menial pedantic stuff. It would be so much easier to merge working code and let it work, and keep those TODOs in the backlog (e.g. trash).

In a sane world, code review would be like:

  1. Will this work and not break anything? We checked it, it's okay. There are no apparent critical or serious issues here.
  2. Here's a list of stuff that you can change if you wish, here's why it might be an improvement.
  3. Okay, we have some left-over nice to haves, let's keep track of those for later (or not) and merge.

It gets infinitely worse if you're working on 3 projects in parallel and the person wants long winded calls or starts nitpicking about naming, or wants things done exactly their way as if it's the only way (doubly worse if their way is actually worse by most metrics and tastes).

Re: Trunk Based Development

#17

Post by Zardoz84 » Sat, Feb 21, 2026, 10:06 AM UTC

F-W-M wrote: post #8

alfiedotwtf wrote: post #7

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, fi…

If you need to support multiple versions at the same time, you need to extend TBD in some way. We just cherry-picked stuff back to release branches, if we needed a fix.

we have a "release" branch and a "develop" branch. The release is trunked on the last released version and (in theory) only gets fixes. If we need to fix a more older version, we create a temporary branch on that version to fix it, and we cherry pick the fixes (or merge to) to release branch and then to develop branch.

The triple mortal loop, comes that we have two versions of the product. One with the old no responsive frontend and other with a modern responsive frontend. And we need to release and develop the two versions for sometime, before the direction decides to kill the old no responsive version. So we end with 4 branches: release, release_rwd, develop and develop_rwd. If we fix something in release, we need to do a diamond merge : release to release_rwd, release to develop, release_rwd to develop_rwd and develop to develop_rwd

Re: Trunk Based Development

#18

Post by swiftcoder » Sat, Feb 21, 2026, 10:06 AM UTC

reywilliams wrote: post #15

swiftcoder wrote: post #5

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.

GitHub[1] is working through this now, hopefully it leads to more adoption. [1]: https://x.com/jaredpalmer/status/2019817235163074881?s=20

Damn! Can't wait

Re: Trunk Based Development

#19

Post by 4pkjai » Sat, Feb 21, 2026, 10:06 AM UTC

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.

Re: Trunk Based Development

#20

Post by ngalaiko » Sat, Feb 21, 2026, 10:08 AM UTC

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