Hacker News Reader

Comment by alkonaut | Hacker News Reader

Trunk based can be sort of ok of you can accept a broken trunk and features can be kept small enough to give meaningful commits. If features require 10 commits and you have several teams working in parallel on different features then you’ll have an interleaved history of various stages of completion of each feature. You need to make each step of each feature shippable if you use CD - so e.g you can’t commit the removal of an old implementation and later add the new implementation.

In all, I’d say the pain of feature branches and PRs is tiny compared to trunk based development, even for teams as small as two.

It’s not the industry standard without reason.

View on HN

I make a point never to commit broken code anyway. If a series of changes have to be together to not break, I put them all in one commit. And for organization’s sake, commits could still be tagged by ticket

That doesn't mean an entire feature has to go in one commit (usually). Often a feature is made up of a series of non-breaking changes that can be layered one at a time, if appropriate.

As a reviewer I really want a series of commits each making closely related changes that are easy to understand. Squashing tends to make giant diffs that replace almost every line, and you almost have to reverse-engineer to figure out what’s actually supposed to be different.

How about with multiple repos, across multiple systems? Eg. embedded device with 4-week test cycles, backend server with CI/CD, frontend site with CI/CD, and upstream vendor contribution PR(s), and where the data fees for firmware updates to the set of all customer embedded devices run into the hundreds of thousands of dollars? You can't get them all in one commit then. Even with a monorepo (not contributing back to upstream) it'd be an utterly massive commit.

That negates one of the major advantages of committing code, which is having a regular backup of your work.

My team makes several commits locally, then rebases, squashes, and pushes the squashed commit to the trunk which has CI. This maintains a local, regular backup of your code and collects features into single commits for the trunk which are easily revertable if found to be problematic. This flow will not work for everyone, but it works very well for us (a team of 8 at a FAANG company).

Edit: Rereading your comment, I suspect you mean non-local backups. Our organization has a special remote only visible to you and those you allow for pushing code you'd like to backup off of your box.

That sounds like feature branches but with more steps and worse. You can't share your unfinished work non-locally, for one thing. And it has none of the advantages of CI because you still have infrequent large merges.

> If a series of changes have to be together to not break, I put them all in one commit.

I'm sorry but it hurts just to read this. Just No.

Please could you expand? Without substance, there’s nothing here that defends your position.

Going back through history to find where a bug was introduced usually happens on the commit level (e.g. git-bisect only operates on commits, naturally). Once you find the commit that introduced the bug in question, it will be immensely easier to hunt down the bug within the commit if the commit is 10 or 50 lines long instead of 500 or 1000.

Feature flags can be helpful here. Even if the feature is incomplete, it’s still ok to commit it.

Another thing that can help is a source control system that supports multiple commits and committing them to the main branch as a contiguous unit. I believe Phabricator supports that.

The next best thing you can do with GitHub is make your pretty series of commits for review, but then squash on completion using the GitHub UI. GitHub retains the individual commits of the PR that we’re reviewed while the main branch history has a single commit that passed CI.

Reply on news.ycombinator.com