Hacker News new | ask | show | jobs
by arnvald 2618 days ago
I've tried trunk-based development before, and while it provides certain benefits, I don't think it's a silver bullet.

> Why you should not use feature branches

> Keep reading, all the objections you can think of are wrong.

The tone of the title and some parts of articles suggests that trunk-based development is objectively better than feature branches. I feel that it's rather a matter of opinion. You might want to try it out, it might work better for you than feature branches. But I don't think saying "feature branches are wrong approach" or "your objections are not valid" is true for everyone.

One example are code reviews.

> If the code review culture is strong in your team then it can very well be done on the commit to the main branch.

Personally I find this inconvenient. Reviewing a single commit does not show me the bigger picture. Let's say I refactor some code before adding a new feature. Refactoring is in a single commit, but to see whether this refactoring makes sense, it's better if the reviewer sees the next step, then they can understand better why I refactored it in this particular way.

> The main thing to improve here is probably not the branching model, but the code review process.

Maybe this is true. Maybe my way of thinking about code reviews is wrong. However, again, I feel it's a matter of preference. I tried both ways and I certainly prefer reviewing the whole feature than single commits.

One more problem I find with trunk-based development: it happened to me before that a developer did something completely wrong. They misunderstood the requirement, they misunderstood the code - it happens, the world's not perfect. With feature branch I'll just ask developer to start from scratch. `git branch -D` and that code is gone. With trunk-based development the code is already in the master branch, and while it obviously can be changed or reverted, it's already there, people already have pulled this code, they modify this code, they look at it and try to understand it, they try to figure out why it's there.

Again, I'm not saying here that trunk-based development is a bad idea. It might be working for you, it might not, everyone's different. I believe the article explains the benefits of trunk-based development pretty well, I wish though it wasn't presented as an objectively superior alternative to feature branches.

1 comments

Fair enough. You have a valid point on "your objections are not valid" is not the right tone. I'll edit to highlight that feature branches have their benefits in some cases. Thanks for reading!
Thank you for considering my comment!
I've updated the sentence with "Here are the common objections one might have and a tentative solution" and extended the conclusion to say "TBD is not the only way to work"