GitHub 29 merges a pull request in one of three ways, which Settings, General, Pull Requests can offer or switch off. They produce the same files and different histories:
| Method | What lands on the base branch | Best for |
|---|---|---|
| Create a merge commit | Every commit, plus a merge commit | Keeping the branch's history |
| Squash and merge | One new commit for the whole change | Branches of work-in-progress commits |
| Rebase and merge | Every commit, replayed with new SHAs | A linear history of clean commits |
BookNest's first three pull requests used one each; #9, a template and an .editorconfig in two commits, was rebased in Auto-Merge:
gh pr merge 7 --squash --delete-branch
gh pr merge 8 --merge --delete-branch
git switch -q main && git pull -q
git log --graph --format='%h %s' -6✓ Squashed and merged pull request binarybehemoth/booknest#7 (Filter books by author) ✓ Merged pull request binarybehemoth/booknest#8 (Document the error responses) * 275ab42 Add an .editorconfig * 9372238 Add a pull request template * dfed92b Merge pull request #8 from binarybehemoth/docs/error-responses |\ | * d6b99f1 Document the error responses * | 33308ca Filter books by author (#7) |/ * 206806f Sort books by title and reject unknown sort keys
The squash 33308ca carries the pull request's title and number, both original messages in its body, and a Co-authored-by: Sam Rivera trailer, since Sam's address is not linked to the merging account. The merge commit keeps d6b99f1 on a side branch. The rebased commits keep Sam as author but get new SHAs (the local branch was adf9822) and the merging account as committer. GitHub signs the squash and merge commits it writes; rebased commits are unsigned. Pick one method per repository: squash suits most applications, rebase suits curated commits, merge commits suit long-lived branches.