Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trunk Based Development

trunkbaseddevelopment.com

Post reply on HN
Print view View original

31–40 of 72 posts

Re: Trunk Based Development

#31

Post by Normal_gaussian »

rsaarsoo wrote: post #29
aidos wrote: post #22

Earlier quoted context omitted.

It’s pretty hard to keep the commits in a working branch in a good legible state - certainly it takes work to do it. In 25 years of professional development I’ve never really had a situation where the commits on a branch would have helped me understand what was going on a year ago when the work was done. That includes pretty big bits of project work. I’d much rather have a trunk with commits at the granularity of fea…

I on the other hand have never come across a scenario where I run git bisect to find a commit that broke something, discover a small commit as a culprit and wish I had instead found a commit that's hundreds of lines long. What has happened a whole lot though is the exact opposite.

It might be better to view a commit as a natural unit of working code. There are a lot of units of working code which would be tedious to be introduced as a only a few lines.

As such, a new codebase is likely to grow by large unwieldy commits and a mature one by targetted small commits.

Re: Trunk Based Development

#32

Post by maccard »

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…

I work in games, and we do commit directly to main. On a smaller team you can get away with pre submit review, post submit checks. On a bigger team you need pre submit checks but honestly the point where you need this is much much later than you think. One of my previous projects had 100+ people committing directly to main with no pre submit checks and jt broke once or twice a day. The builds took longer than that to go through so you just always sync to “last known good”

Re: Trunk Based Development

#33

Post by barrkel »

aidos wrote: post #22
ahartmetz wrote: post #21

Earlier quoted context omitted.

Why in the world would you do squash merges? ...except to clean up messy mini-branches written by total noobs. I don't do separate commits for funzies. If you want separate commits for ease of review, why not for later reading of the code. Assumption: above mentioned total noobs don't use git rebase -i or equivalent, everyone else does

It’s pretty hard to keep the commits in a working branch in a good legible state - certainly it takes work to do it. In 25 years of professional development I’ve never really had a situation where the commits on a branch would have helped me understand what was going on a year ago when the work was done. That includes pretty big bits of project work. I’d much rather have a trunk with commits at the granularity of fea…

I'd much rather reduce the risk of mutation to the trunk, by having small easily reviewable commits direct to trunk.

It's less about reviewing commits from a year ago, than making change low-risk today. And small commits can easily be rolled back. The bigger the commit, the more likely rollback will be entangled.

It better to have partial features committed and in production and gated behind a feature flag, than risk living in some long-lived branch.

Re: Trunk Based Development

#35

Post by skydhash »

lloeki wrote: post #27
aidos wrote: post #22

Earlier quoted context omitted.

It’s pretty hard to keep the commits in a working branch in a good legible state - certainly it takes work to do it. In 25 years of professional development I’ve never really had a situation where the commits on a branch would have helped me understand what was going on a year ago when the work was done. That includes pretty big bits of project work. I’d much rather have a trunk with commits at the granularity of fea…

In 25 years of professional development I have several counter examples where some bit was either a trivial git revert of a single commit - among multiple ones in a branch - away, or an absolute pain because the squash-merge commit had flattened too many concerns together, concerns that were perfectly split in the topic branch but that branch was long gone by virtue of being auto-deleted on PR merge. Coincidentally,…

If you work with a ticket system, squash-merge gives you the same granularity, where a commit would refer to a single ticket.

A ticket should be atomic describing a single change request. PR in this case are the working room. It can be as messy or as clean as you want. But the goal is to produce a patch that introduces one change. Because if you would rebase -i at the end, you would have a single commit too in the PR.

Re: Trunk Based Development

#36

Post by locknitpicker »

ahartmetz wrote: post #21
locknitpicker wrote: post #14

Earlier quoted context omitted.

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

Why in the world would you do squash merges? ...except to clean up messy mini-branches written by total noobs. I don't do separate commits for funzies. If you want separate commits for ease of review, why not for later reading of the code. Assumption: above mentioned total noobs don't use git rebase -i or equivalent, everyone else does

> Why in the world would you do squash merges?

Why would you not want to squash merges? It's one of three options offered by GitHub in their PR merge buttons.

They create a linear commit history, which is what you want when you have to audit changes.

> except to clean up messy mini-branches written by total noobs.

Nonsense. You get a messed up commit history as easily as when you create a PR in GitHub, and after team members merge their commits, you click on GitHub's "update branch" button.

You also get a messed up commit history if you merge a PR after someone else merged theirs.

You will always mess up your pristine commit history if you have more than one person posting and merging branches. With one notable exception: squashed commits.

Re: Trunk Based Development

#37

Post by locknitpicker »

barrkel wrote: post #33
aidos wrote: post #22

Earlier quoted context omitted.

It’s pretty hard to keep the commits in a working branch in a good legible state - certainly it takes work to do it. In 25 years of professional development I’ve never really had a situation where the commits on a branch would have helped me understand what was going on a year ago when the work was done. That includes pretty big bits of project work. I’d much rather have a trunk with commits at the granularity of fea…

I'd much rather reduce the risk of mutation to the trunk, by having small easily reviewable commits direct to trunk. It's less about reviewing commits from a year ago, than making change low-risk today. And small commits can easily be rolled back. The bigger the commit, the more likely rollback will be entangled. It better to have partial features committed and in production and gated behind a feature flag, than risk…

> I'd much rather reduce the risk of mutation to the trunk, by having small easily reviewable commits direct to trunk.

You're not addressing the problem. You're just wishing that the problem wouldn't happen as frequently as it does.

But that's like wishing that race conditions don't happen by making your allocations at a higher frequency.

Re: Trunk Based Development

#38

Post by xen0 »

ahartmetz wrote: post #21
locknitpicker wrote: post #14

Earlier quoted context omitted.

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

Why in the world would you do squash merges? ...except to clean up messy mini-branches written by total noobs. I don't do separate commits for funzies. If you want separate commits for ease of review, why not for later reading of the code. Assumption: above mentioned total noobs don't use git rebase -i or equivalent, everyone else does

I want every commit to represent a buildable state in which I have confidence automated tests pass. Bisecting is made unnecessarily difficult otherwise, and it's nice to be able checkout any commit and just build something for testing.

This constraint is usually enforced by code review.

On Github, the unit of code review is the PR.

Therefore, I prefer squashing.

Re: Trunk Based Development

#39

Post by barrkel »

locknitpicker wrote: post #37
barrkel wrote: post #33

Earlier quoted context omitted.

I'd much rather reduce the risk of mutation to the trunk, by having small easily reviewable commits direct to trunk. It's less about reviewing commits from a year ago, than making change low-risk today. And small commits can easily be rolled back. The bigger the commit, the more likely rollback will be entangled. It better to have partial features committed and in production and gated behind a feature flag, than risk…

> I'd much rather reduce the risk of mutation to the trunk, by having small easily reviewable commits direct to trunk. You're not addressing the problem. You're just wishing that the problem wouldn't happen as frequently as it does. But that's like wishing that race conditions don't happen by making your allocations at a higher frequency.

I'm describing how Google works with teams with high release cadence, fwiw.

Also, your comment reads a little bit as a non sequitur.

Re: Trunk Based Development

#40

Post by Longwelwind »

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…

Trunk-based development fits nicely when you have a single deployment product like a SaaS and you don't need to maintain old versions of your software. You only have one prod environment.

If you build a software that you distribute so people can deploy it themselves (a library, a self-hostable solution, ...), then you most likely semantic versioning. In that case, the best model is to use what semantic release offers.

Post reply on HN