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.

Before the Merge

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

• 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:

• 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:

• 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:

• 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

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