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

21–30 of 72 posts

Re: Trunk Based Development

#21

Post by ahartmetz »

locknitpicker wrote: post #14
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.

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

Re: Trunk Based Development

#22

Post by aidos »

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

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

Re: Trunk Based Development

#23

Post by ahartmetz »

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.

I think Gerrit has something like stacked PRs - and incidentally it's used for Chromium and was created for running its own public open source projects by Google. It's also used by the Qt project, which is where I sometimes use it.

Gerrit looks ugly and is not very easy to use at first, but at least it's not slow like GitLab and GitHub.

Re: Trunk Based Development

#24

Post by Hamuko »

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.

What's the benefit of stacked PRs?

Re: Trunk Based Development

#25

Post by groestl »

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…

100%. I don't want to know how the sausage was made. It's similar to research papers, or history books, where the way we arrive at results or outcomes in the real world is often quite different from the way it's presented in the final form.

Re: Trunk Based Development

#26

Post by sodapopcan »

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…

`git log --merges --first-parent` gives you both.

I've had separate commits come in handy several times when `git blame`ing when working with people who actually described what changes were about in their commits (which, unlike comments, don't go out of date).

Re: Trunk Based Development

#27

Post by lloeki »

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…

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, every single squash-merge commit advocate I've had the unfortunate debate with was a regular practitioner of public tmp / tmp / try again / linter / tmp / fix / fix / haaaaaands commits.

Note that I'm not against squashing/history rewriting e.g rebase -i and stuff (which I'm a heavy user of so as to present sensible code aggregation reviewable per-commits), only squash-merge.

Re: Trunk Based Development

#28

Post by swiftcoder »

Hamuko wrote: post #24
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.

What's the benefit of stacked PRs?

It's basically automatic rebasing of a set of PRs built on top of each other. Makes it easy to split large changes into manageable pieces that are asymmetrical for your colleagues to review individually, and makes it easy to maintain feature branches long enough to get the feature working end-to-end

Re: Trunk Based Development

#29

Post by rsaarsoo »

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

Re: Trunk Based Development

#30

Post by VorpalWay »

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…

Each commit should be small, have a descriptive commit message and be stand alone. I consider the Linux kernel a good example of how to do commits and messages right. Often the commit message is longer than the code change.

I strive to do that when making commits for work too, and that helps when going back in history and looking at history to motivate why a change was made.

While working I rebase all the time to move changes into the relevant commit, I don't find that particularly hard or time consuming. Doing this upfront is easy, splitting commits after the fact is not.

I consider this standard practice, at least in the sector I work in (industrial equipment control software, some of which is considered human safety critical).

Post reply on HN