Hacker News Reader

Comment by u801e | Hacker News Reader

> I personally prefer merging via squash since it keeps a linear commit history without polluting the history with tons of intermediate work-in-progress commits.

How do you deal with cases where your changes require more than a single commit? Some changes are easier to review when they're separated into several logical commits rather than having one giant diff from a single commit.

View on HN

I deal with that by keeping the separate logical commits, like you said, and I squash only the commits that don't add any historical meaning (like "fix a typo" or "forgot to update the changelog"). I put the issue number in the comments so you can view the history and see a group of commits are all related to a single issue.

The squash is only performed when merging the pull request (via GitHub’s merge button on the pull request). The actual work is done and reviewed as individual commits.

The nice part of this workflow is that the changes are all squashed into a single commit in the trunk, but there’s always a link to the pull request where you can see the individual commits pre-squash.

Does the individual commits pre-squash still exist in the repo or are they only saved in the PR, ie. duplicated and saved somewhere in Github's infrastructure?

Yes, the original individual commits are kept alive and never garbage collected from GitHub's copy of the repository. You can get back to them on the website via the "Commits" tab of the PR. Local clones won't contain those branches though unless you explicitly fetch them.

You can rebase locally into commits that make sense and then merge normally on GitHub.

Reply on news.ycombinator.com