Hacker News Reader

For me it's a combination of commiting often and keeping the history readable. To achieve both I have to a) squash commits before merging otherwise I end up with dozens of intermediate commits and b) rebase, otherwise I end up with a history that looks like the Tokyo subway system.

View on HN

Downside of squashing as opposed to making a merge commit (without fast forward) or merging by rebasing, however, is losing granularity. Later it'll be hard to roll back a small part of PR while keeping rest of the changes.

Also it'll be harder to go back and review changes when troubleshooting issues because formatting changes were squashed together with business logic changes. With merges at least there are still original commits available, and it'll be possible to either rollback everything or a single commit.

I could be wrong, I feel like OP is talking about the workflow where the entire branch is squashed before it is integrated into the main branch, not squashing intermediary commits into more logical ones (which is what I think you are talking about).

Reply on news.ycombinator.com