Hacker News Reader

Comment by bluefirebrand | Hacker News Reader

> Bonus points for no PR’s and trunk driven development as that shows a very mature team.

I'm not sure what Trunk Driven Development is, could you elaborate?

I’m assuming based on gp everyone merges into master, no one reviews each other commits. Very uh.. mature

Btw trunk based in general can still have short lived branches and prs. That’s what most public projects on github are doing

https://trunkbaseddevelopment.com/

https://trunkbaseddevelopment.com/trunk1c.png

So trunk driven development means no PRs, until you decide you want to use PRs?

Trunk-based development, as I've seen it explained in the past, isn't what that site describes. The way I understood it is, no branches at all, everything committed straight to trunk, and extensive use of feature flags to keep incomplete features hidden.

Short-lived branches like that site's describing just sounds like a team that's adopted git pretty well, but not formalized usage into gitflow or similar...

It's optional, I guess because so many companies or teams would immediately discard TBD if this wasn't addressed.

What’s the benefit of having release branches without commits if you can just use tags? I guess the difference is mostly cosmetic?

It’s trunk driven because there aren’t some long lived branches like ‘dev’ and ‘staging’ or ‘release-xx’

Feature flags can be used to gate features until they are ready, but all code is committed to trunk and is deployed to prod mostly continuously.

Okay now I'm wondering what the alternative is, because this just looks like "development" to me.

Gitflow, and its various flavours, has been a popular alternative. Though it seems trunk-based is considered the preferred standard due to emphasis on achieving a stable main branch, simplified pipelines and faster cycle times. This requires a bit more maturity to get right if I'm not mistaken as you need good automation, test coverage and code review practices.

I've never heard of Gitflow or anything. I've been doing this stuff for almost a decade and trunk based with short lived development branches is all I've ever seen.

Bizarre.

Funnily enough, I've never heard of trunk based, but the flow described is what I have heard called the 'github flow'.

Yeah, it was pretty popular for a while but I doubt many people really do it because of it’s shortcomings. I guess if you spent most of your time in feature freezes trying to stabilise the upcoming release of your product, but I’ve often felt it’s better to either just have a few feature branches queued ready to merge once the master branch is tagged and released, or to branch master into a release branch once you have a feature freeze and only commit bug fixes to that. But then you have the annoyance of having to cherry-pick features between the branches.

It's good that people experiment with new ideas I guess, but in my 27 years as a software developer all the progress I've seen is towards continuous integration and testing. The more branches and configurations there are, the slower development is and the lower overall quality is. Sometimes there are advantages to counterbalance that, and if you've got a huge team and a huge user base it may be worth the cost. But a strong default bias towards less branches, less options, test more often, merge sooner, deploy sooner has always worked better than fancy alternatives.

Alternative is having long lived “devel” branches or even dedicated release branches. Used to be quite popular especially with waterfall style processes

Virtually all game companies use Trunk Based Development, in my experience, including many very large studios. (Outside of game engine development, which isn't really done by game studios anymore with a few exceptions)

Interesting, I wonder if that's why you see insane build numbers like 1.2.4045.26836?

I suspect you'll find that two of those numbers are decided by committee, one by a human, and the other by the build system.

There's good odds that it's the 26836th build, the 4045th snapshot, and the second time they've broken the file format. (or the 2nd expansion, or both)

Do you follow a style of git behavior now? I transitioned from purely git flow projects to most of my time on a trunk-based team this year.

Pretty striking difference.

Reply on news.ycombinator.com