GitHub Merge Strategies: A Visual Explanation

Discussion started up at work this week about the different merge strategies available in GitHub. I looked around online to see if I could find a good article to send to share a quick snapshot of the differences represented visually and didn’t find any I liked, so here’s my take!

Merging your Pull Request

You wrote all your code and are ready to merge! Let’s go! At the bottom of your Pull Request (PR) you’ll find a button with a drop down arrow that shows three options with descriptions, but what do they actually do? Sometimes it’s helpful to actually see how these things play out.

GitHub merge dialog showing three options. Create a merge commit: All commits from this branch will be added to the base branch via a merge commit. Squash and merge: The 10 commits from this branch will be combined into one commit in the base branch. Rebase and merge: The 10 commits from this branch will be rebased and added to the base branch.

Before the Merge

(aka you wrote code on feature-branch and are ready to merge back to main)

A diagram showing the main branch with commits D to E and a feature branch with commits A to B to C

main branch: D → E
feature-branch branched from D and adds commits A → B → C

1. Merge Commit

Preserves full commit history
Shows when branches were merged
Creates an extra merge commit (M)

After merge:

A diagram showing the main branch with commits D to E to M and a feature branch with commits A to B to C to M showing that M is a new commit on the main branch merging the changes.

The feature branch is merged with all its history intact.
A new merge commit (M) is created.
- These usually read like Merge pull request #---- from feature-branch in your git history.

2. Squash Merge

Clean history with a single commit
Loses individual commits from the feature branch

After squash merge:

A diagram showing the main branch with commits D to E to S and a feature branch with commits A to B to C showing that S is a new commit on the main branch merging the changes that were combined from A, B, and C.

The entire A → B → C branch is squashed into a single commit S, removing individual commits.

3. Rebase Merge

Retains individual commits
Creates a linear history
Rewrites commit history (be careful in shared branches)

After rebase:

A diagram showing the main branch with commits D to E to A prime to B prime to C prime. This represents that A, B, and C are rebased on top of the Head of main, but are fundamentally new commits since they have new parent commits.

The commits are replayed on top of main, making history linear.
New commit hashes (A', B', C') are created because their parent commits changed.

Final Comparison

Merge Type	Keeps Individual Commits?	Keeps Merge Info?	Linear History?	Creates Extra Commit?
Merge Commit	✅ Yes	✅ Yes	❌ No	✅ Yes (`M`)
Squash Merge	❌ No (One Commit)	❌ No	✅ Yes	✅ Yes (`S`)
Rebase Merge	✅ Yes	❌ No	✅ Yes	❌ No

Which one do you prefer? Let me know and thanks for reading!

GitHub Merge Strategies: A Visual Explanation

Comments

More from this blog

You Should Make a Hype Channel

No Permanent Overrides

Demo Why Not What

Introducing Dejavu: Recomposition Testing for Jetpack Compose

Cook Together, Clean Together, Build Together

Merging your Pull Request

Before the Merge

1. Merge Commit

2. Squash Merge

3. Rebase Merge

Final Comparison

Command Palette

Comments

More from this blog

Merging your Pull Request

Before the Merge

1. Merge Commit

2. Squash Merge

3. Rebase Merge

Final Comparison