11 ms·

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.

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. A linear history is helpful when debugging since it makes git bisect a lot easier. Having individual PR commits in the history makes git bisect useless since it’s unfortunately common for individual PR commits to leave the system in a broken state.

u801e 9y ago
> 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.
- faitswulff 9y ago
  You can rebase locally into commits that make sense and then merge normally on GitHub.
- mpetrovich 9y ago
  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.
  - mnsc 9y ago
    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?
    - jmuhlich 9y ago
      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.
- gonewest 9y ago
  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.

u801e 9y ago

> 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.

faitswulff 9y ago
You can rebase locally into commits that make sense and then merge normally on GitHub.
mpetrovich 9y ago
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.
- mnsc 9y ago
  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?
  - jmuhlich 9y ago
    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.
gonewest 9y ago
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.