Intermediate · 5 min read

Merge, squash or rebase: merging a pull request

The three buttons of GitHub, what they do to history, and which one to choose.

Create a merge commit

Keeps every commit of the branch plus a merge commit. Full history, but noisy with “fix typo” commits. Undo with git revert -m 1.

Safe

$ git merge --no-ff feat/dark-mode

Squash and merge

All the PR's commits become one commit on main. Clean history, one commit per feature, easy to revert. The branch's own commits stay out of main: delete the branch after.

Safe

$ git merge --squash feat/dark-mode
$ git commit

Rebase and merge

Replays each commit on top of main, no merge commit. Linear history that keeps every commit: the PR's commits must be clean.

Which one?

Most teams: squash and merge (one PR = one commit). Clean, well-split commits worth keeping: rebase and merge. Long-lived branches (release): merge commit. Pick one and enforce it in the repository settings.

After a squash merge

Your local branch looks “not merged” to Git (different commits). That's normal: delete it with -D once you checked the PR is merged.

Safe

$ git switch main && git pull
$ git branch -D feat/dark-mode