Hacker News Reader

Comment by ianlevesque | Hacker News Reader

This is one thing that the FAANG workflow gets right. Multiple stacked commits are great as long as each one is a reviewable unit that makes sense on its own, and they don't need to be squashed to merge to main. What you need to avoid are a stack of commits like "added some code today" and "fixed bugs" and "try #3". Learn to amend existing commits instead...

View on HN

> What you need to avoid are a stack of commits like "added some code today" and "fixed bugs" and "try #3".

That’s what you need to avoid in your mainline. Mandating what developers do in development branches is like having a dress code at work and then complaining about your colleague’s choice of underwear.

Nobody cares about the underwear... until people create a PR explicitly saying "look at my underwear".

And GitHub makes it 1-click easy to make a pull request full of underwear so it happens all the time.

Nobody mandates developers about their private repos and commits, nobody cares about that. This is about what gets merged into master or what gets submitted for review.

Squashing commits loses history, rebasing messy commits pollutes the "first parent" history, merging messy commits is cleaner but can force bisectors to wade through dead ends (which may or may not be useful, and may be worth preserving in a permanent side branch not merged), and rewriting commit histories into atomic commits (what I do most of the time) is difficult work which can take as long as writing the features upfront, and if done wrong can produce non-building commits. Sadly I haven't found a good solution for the workload yet, but this article suggests `git rebase -i main --exec "make"`, which I'll be sure to try when I have a chance.

Reply on news.ycombinator.com