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

51–60 of 72 posts

Re: Trunk Based Development

#51

Post by xen0 »

ahartmetz wrote: post #44
xen0 wrote: post #38

Earlier quoted context omitted.

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.

>On Github, the unit of code review is the PR. It is, and that is some bullshit. The only sensible way to work with that is to break up larger features into several PRs - which is often positive anyway, but sometimes it doesn't fit the nature of the change.

I am not a fan of Github's interface.

But my point is, is that I believe the important thing to preserve in history is whatever your unit of review is. If you could stack PRs and each were subject to the individual review, I would not combine and squash those (just the individual commits within each PR).

Re: Trunk Based Development

#52

Post by swiftcoder »

amabito wrote: post #47
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.

The tooling gap exists partly because git's data model has no native concept of "this branch's upstream is another feature branch" — each PR is independent from the forge's perspective, so rebasing one layer in the stack requires manually re-targeting every PR below it. FAANG-internal tools solve this by storing the stack relationship in a metadata layer outside git itself, then regenerating the PR graph after each r…

We seem to be reaching some sort of consensus among major code review partners on a standard for this information[1]

[1]: https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...

Re: Trunk Based Development

#53

Post by SeriousM »

ngalaiko wrote: post #20

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

Thats my situation. We're 5 devs for 5 years on a monorepo with about 50 services and worked on master without problems. Just from time to time a merge conflict. The only difficulty is to manage Release branch(es) with hotfixes. Discipline, Thinking and Working together, that's the magic source.

Re: Trunk Based Development

#54

Post by skydhash »

sodapopcan wrote: post #50
skydhash wrote: post #48

Earlier quoted context omitted.

Those looks more like noise to me. A squashed merge (or a final squash before PR) would be: TN 43 - Fix mismatched interface between Foo and Bar We've moved the X property to a more appropriate place and improved the documentation for Feature Foo. We've also found and fix an O(n^2) implementation in feature Bar. The the ticket TN-43 will have all the details that have lead to the PR being made: Bug reports, investiga…

They aren't noise at all and have found them useful a bunch in the past when I worked at a place that didn't squash. Commits at this level act as immutable comments that don't get out of date. Provided you do --no-fast-forward merges, the merge commit is the feature commit and you can get the "clean" feature history with `git log --merges --first-parent`. Best of both worlds! Being able to `git blame` and get a granu…

I get where you came from, but I prefer having a more holistic view of a change, especially from a product perspective. So even when git-blaming, either I’m reading the current file or I go straight to the log of the commit (with message and diff).

I prefer granularity at a product or team level decision. Not workflow details.

Re: Trunk Based Development

#55

Post by ahartmetz »

xen0 wrote: post #51
ahartmetz wrote: post #44

Earlier quoted context omitted.

>On Github, the unit of code review is the PR. It is, and that is some bullshit. The only sensible way to work with that is to break up larger features into several PRs - which is often positive anyway, but sometimes it doesn't fit the nature of the change.

I am not a fan of Github's interface. But my point is, is that I believe the important thing to preserve in history is whatever your unit of review is. If you could stack PRs and each were subject to the individual review, I would not combine and squash those (just the individual commits within each PR).

>I believe the important thing to preserve in history is whatever your unit of review is

I do not share that belief, but this thread (your posts and others) gave me an idea about code reviews. They became commonplace when I'd been working in software for a while already and, while I see the benefits, I never really felt like I handled them well. I guess one of the ingredients for handling them better is to center the workflow around them - an area in which I have never noticed major changes in an existing project, although they are visible when looking from the right angle: Long-lived, large feature branches have become noticeably less common.

Re: Trunk Based Development

#56

Post by sodapopcan »

skydhash wrote: post #54
sodapopcan wrote: post #50

Earlier quoted context omitted.

They aren't noise at all and have found them useful a bunch in the past when I worked at a place that didn't squash. Commits at this level act as immutable comments that don't get out of date. Provided you do --no-fast-forward merges, the merge commit is the feature commit and you can get the "clean" feature history with `git log --merges --first-parent`. Best of both worlds! Being able to `git blame` and get a granu…

I get where you came from, but I prefer having a more holistic view of a change, especially from a product perspective. So even when git-blaming, either I’m reading the current file or I go straight to the log of the commit (with message and diff). I prefer granularity at a product or team level decision. Not workflow details.

I'm not trying to convince you to adopt or anything, but I'm saying you can have all of that without squashing with the caveat that you would need an alias to jump to the merge commit. Otherwise, you just treat merge commits as you would a squash one. Merge commits are just like regular commits that can have a custom message and show a diff.

Re: Trunk Based Development

#57

Post by eddd-ddde »

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…

I've commented about this before.

The answer is development branches are forbidden but releases still use a kind of branching approach.

When you make a release you use commit A from main, then development continues, commit B adds a feature, and maybe commit C fixes a serious bug.

You don't want to make a new release at C because it includes new non tested features, instead you cherry-pick fixes to your release, test the new release candidates, and release that when ready.

Development still happens in main however.

Another big tool to minimise these problems is to separate the concept of feature release from the concept of binary release. You don't have to make a true deployment to release new features or roll them back, just use a toggle switch.

Re: Trunk Based Development

#58

Post by locknitpicker »

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

My professional experience contrasts with yours. I've even worked at a company where commit history and PRs were so central to understand and explain changes that PRs were even used as the authoritative sources on how to implement features and use frameworks.

Re: Trunk Based Development

#59

Post by locknitpicker »

skydhash wrote: post #35
lloeki wrote: post #27

Earlier quoted context omitted.

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…

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

With GitHub you can squash any PR merge. The link to the PR will include the complete history of the feature branch prior to the merge. Even the commit history prior to force pushes is tracked.

Re: Trunk Based Development

#60

Post by estimator7292 »

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?

Post reply on HN