Squash and Merge vs Merge Commit vs Rebase and Merge: When to Use Each

When a pull request is finally ready to merge, GitHub offers three distinct strategies for actually doing so, each producing a meaningfully different shape of resulting history — building directly on Module 3's merge concepts and Module 4's rebase concepts, now applied specifically to the moment of merging a pull request.

Learning Objectives

Explain what each of GitHub's three merge strategies does to a pull request's commit history.
Compare the resulting history shape produced by each strategy.
Identify the practical trade-offs that inform choosing one strategy over another.
Understand how to configure which strategies are available (or default) for a repository.

Key Terms to Know Before Choosing a Merge Strategy

Merge commit (Create a merge commit): The default GitHub strategy, performing a standard three-way merge (Module 3) that preserves every individual commit from the PR branch, plus a new merge commit.
Squash and merge: A strategy that combines every commit in a pull request into a single new commit on the base branch, discarding the individual commit history of the branch.
Rebase and merge: A strategy that replays every individual commit from the PR branch directly onto the base branch, without creating any merge commit, similar in spirit to Module 4's git pull --rebase.
Repository merge settings: Configuration under a repository's Settings > General that controls which of the three strategies are enabled and, optionally, which is the default choice.

How the Three GitHub Merge Strategies Actually Work

**Merge commit** ('Create a merge commit') is GitHub's default strategy, and it works exactly like the three-way merge covered in Module 3: every individual commit from the pull request's branch is preserved in the base branch's history exactly as it was, and a new merge commit is created on top, explicitly recording that this branch was merged. This is the most information-preserving option — every incremental commit, including any 'fix typo' or 'address review feedback' commits made during development, remains permanently visible in history, and the merge commit itself provides a clear, explicit marker of exactly when and what was integrated.

**Squash and merge** takes the opposite approach: instead of preserving individual commits, it combines every commit in the pull request into a **single new commit** on the base branch, with a commit message you can edit at merge time (often auto-suggested from the PR's title and description). All of the branch's incremental history — every small fix, every 'address review comments' commit — is discarded from the base branch's permanent history, replaced by one clean, focused commit representing the PR as a whole. This is especially popular for keeping a project's main branch history simple and readable, since messy, iterative development history (which is often genuinely useful *during* review, but not particularly meaningful afterward) never clutters the permanent record.

**Rebase and merge** takes yet a third approach, closely related to Module 4's `git pull --rebase`: every individual commit from the pull request is replayed directly onto the tip of the base branch, one by one, in order — preserving each individual commit (unlike squash) but with **no merge commit created at all** (unlike the merge commit strategy), resulting in a fully linear history. This preserves the granularity of squash's opposite (full commit-by-commit history) while still achieving the clean, straight-line shape that a plain merge commit strategy doesn't provide.

Choosing between these three is often a matter of team philosophy, and directly parallels the trade-offs discussed in Module 3 and Module 4's merge/rebase lessons:

- Choose **merge commit** if you value preserving complete, granular history, including a clear, explicit record of exactly which commits belonged to which merged feature.
- Choose **squash and merge** if you value a clean, simple main branch history above all, and don't mind losing the granular, often messy incremental commits made during a feature's development.
- Choose **rebase and merge** if you want both a fully linear history *and* to preserve every individual commit's granularity — though be aware this can result in many small, individually less meaningful commits permanently in your main branch history if a team's commit habits during development aren't already fairly clean.

Repository administrators can configure exactly which of these three strategies are even available as options (Settings > General > Pull Requests), and many teams deliberately restrict this to just one consistently enforced strategy — most commonly **squash and merge**, given its popularity for keeping a clean, simple main branch history without requiring every contributor to practice perfectly clean, atomic commit habits during development.

Squash vs Merge Commit vs Rebase and Merge: Visual Walkthrough

Draw the same starting point (a feature branch with three commits: C1, C2, C3, branching off main at commit M). Show three separate outcomes after merging via each strategy. LEFT 'Merge commit': main now shows M → (new merge commit) with two parent lines back to M and C3, and C1/C2/C3 all individually visible in history. MIDDLE 'Squash and merge': main now shows M → S (ONE new commit combining C1+C2+C3), with C1/C2/C3 no longer individually visible. RIGHT 'Rebase and merge': main now shows M → C1' → C2' → C3' in a single straight line, each individually visible but with new hashes, no merge commit.

GitHub Merge Strategies: Key Differences

Strategy	Individual Commits Preserved?	Merge Commit Created?	Resulting History Shape
Merge commit	Yes, exactly as they were	Yes	Branching, with an explicit merge point
Squash and merge	No — combined into one commit	No (the squash commit replaces them)	Linear, but with one commit per PR
Rebase and merge	Yes, but with new hashes	No	Fully linear, with each original commit individually visible

The Three Merge Strategies: Resulting History Examples

# Starting point: a feature branch with 3 commits, branched from main
# C1: "wip: start dark mode toggle"
# C2: "fix: correct css variable name"
# C3: "address review feedback: rename function"

# --- Merge commit strategy result on main ---
# ... M ... -> Merge commit (parents: M and C3) -> [C1, C2, C3 all individually visible]

# --- Squash and merge strategy result on main ---
# ... M ... -> S: "feat: add dark mode toggle (#87)"  <- ONE commit, C1/C2/C3 no longer separately visible

# --- Rebase and merge strategy result on main ---
# ... M ... -> C1' -> C2' -> C3'   <- each commit individually visible, new hashes, no merge commit, fully linear

Breaking Down the Merge Strategy Comparison Example

Starting from the same three-commit feature branch — including two commits (`wip: start dark mode toggle` and `fix: correct css variable name`) that are genuinely useful to see during review but not particularly meaningful as permanent history — the three strategies produce visibly different results on `main`. The merge commit strategy keeps all three exactly as they were, plus an explicit merge commit. Squash and merge replaces all three with one clean, well-described commit (`feat: add dark mode toggle (#87)`), discarding the noisy intermediate commits entirely. Rebase and merge keeps all three individually visible but with new hashes and no merge commit, producing a fully linear history — illustrating exactly why squash and merge is often preferred specifically when a team's individual development commits (like `wip:` or `fix: correct css variable name`) aren't meant to be part of the project's permanent, readable history.

How Merge Strategies Are Chosen on Real Engineering Teams

Many teams, especially those without strict commit message discipline during active development, default to 'Squash and merge' specifically to guarantee a clean main branch history regardless of how messy individual feature branch commits were.
Projects that value complete traceability — knowing exactly which specific commit introduced which specific change, even mid-feature — often prefer the standard 'Merge commit' strategy, sometimes combined with the --no-ff convention from Module 3.
Some highly disciplined teams that already enforce atomic, well-messaged commits (Module 1) prefer 'Rebase and merge', since it gives them both a fully linear history and the complete, granular commit-by-commit record without needing to sacrifice one for the other.
GitHub repository administrators frequently restrict available merge strategies to just one option (commonly Squash and merge) specifically to enforce team-wide consistency, rather than leaving the choice up to whoever happens to click the merge button for a given PR.

Merge Strategy Interview Questions and Answers

Q1. What is the difference between 'Merge commit' and 'Squash and merge' as GitHub PR merge strategies?

Merge commit preserves every individual commit from the pull request exactly as it was, plus creates a new merge commit recording the integration — following the standard three-way merge behavior. Squash and merge instead combines every commit in the pull request into a single new commit on the base branch, discarding the branch's individual, often messy incremental commit history.

Q2. How does 'Rebase and merge' differ from both of the other two strategies?

Like Merge commit, it preserves every individual commit from the pull request (unlike Squash, which combines them into one). But like Squash, it creates no merge commit at all (unlike Merge commit), instead replaying each commit directly onto the base branch with new hashes, resulting in a fully linear history that still shows every individual commit.

Q3. Why might a team choose to restrict their repository to only one available merge strategy?

To enforce consistency across all contributors, rather than leaving the resulting history shape dependent on whichever strategy an individual happens to select when merging a given pull request. Squash and merge is a particularly common choice for this, since it guarantees a clean main branch history regardless of how messy individual feature branch commits were during development.

Merge Strategies Quiz: Test Your Understanding

1. What does the 'Squash and merge' strategy do to a pull request's individual commits?

Preserves each one exactly as it was
Combines all of them into a single new commit on the base branch
Deletes them without adding anything to the base branch
Converts them into a new branch

Answer: B. Combines all of them into a single new commit on the base branch

Explanation: Squash and merge discards the pull request's individual, incremental commit history, replacing it with one combined commit representing the PR as a whole.

2. Which merge strategy preserves individual commits AND produces a fully linear history with no merge commit?

Merge commit
Squash and merge
Rebase and merge
None of them

Answer: C. Rebase and merge

Explanation: Rebase and merge replays each individual commit from the PR directly onto the base branch with new hashes, preserving granularity while avoiding both a merge commit and the history-flattening effect of squashing.

3. Which merge strategy is GitHub's default, following the standard three-way merge behavior from Module 3?

Squash and merge
Rebase and merge
Merge commit
There is no default

Answer: C. Merge commit

Explanation: 'Create a merge commit' is GitHub's default strategy, preserving every individual commit from the PR branch exactly as it was, plus creating a new merge commit — identical in behavior to a standard three-way merge.

Common Mistakes When Choosing a Merge Strategy

Assuming all three merge strategies produce the same resulting history, when they differ significantly in whether commits are preserved individually, combined, or given new hashes.
Choosing 'Squash and merge' without realizing individual commit granularity is permanently lost from the base branch's history as a result.
Leaving all three strategies enabled on a repository without team-wide agreement, resulting in inconsistent history shapes depending on who merges a given PR.
Confusing 'Rebase and merge' with the local git pull --rebase workflow from Module 4 — they're conceptually related but operate at different points (a PR merge on GitHub vs. syncing your own local branch).

Merge Strategies: Exam-Ready Quick Notes

Merge commit (default): preserves all individual commits + creates a merge commit.
Squash and merge: combines all commits into ONE new commit, discarding individual commit history.
Rebase and merge: preserves individual commits (new hashes) with NO merge commit — fully linear.
Repository Settings > General > Pull Requests: controls which strategies are enabled/default.

Merge Strategies: Key Takeaways

GitHub's three merge strategies produce meaningfully different resulting history shapes, not just cosmetic differences.
Squash and merge is popular for guaranteeing a clean main branch history regardless of how messy a feature branch's development commits were.
Teams should deliberately choose and often enforce one consistent strategy, rather than leaving the choice ad hoc per pull request.

Frequently Asked Questions About GitHub Merge Strategies

Q1. What are the three pull request merge strategies GitHub offers?

Merge commit (the default, preserving all individual commits plus a new merge commit), Squash and merge (combining all commits into one), and Rebase and merge (preserving individual commits but with new hashes and no merge commit, producing a linear history).

Q2. What is the difference between Squash and merge and Rebase and merge?

Squash and merge combines every commit in a pull request into a single new commit, discarding the individual commit history. Rebase and merge preserves each individual commit (with new hashes) but arranges them in a fully linear history with no merge commit created.

Q3. Why do many teams prefer Squash and merge?

It guarantees a clean, simple main branch history — one commit per merged pull request — regardless of how messy or numerous the individual development commits on the feature branch were, without requiring every contributor to maintain perfectly clean commit habits.

Q4. Does Rebase and merge create a merge commit?

No. Unlike the Merge commit strategy, Rebase and merge produces no merge commit at all — it replays each individual commit directly onto the base branch, resulting in a fully linear history.

Q5. Can I control which merge strategies are available on my GitHub repository?

Yes. Under the repository's Settings > General > Pull Requests, an administrator can enable or disable each of the three strategies, and many teams restrict this to just one consistently enforced option.

Summary

GitHub offers three distinct pull request merge strategies, each producing a meaningfully different resulting history. Merge commit, the default, follows Module 3's standard three-way merge behavior — preserving every individual commit from the PR branch exactly as it was, plus a new merge commit. Squash and merge combines every commit in the pull request into a single new commit on the base branch, discarding individual, often messy incremental history in favor of one clean, focused commit per PR. Rebase and merge, closely related to Module 4's `git pull --rebase`, replays every individual commit onto the base branch with new hashes, preserving granularity while producing a fully linear history with no merge commit at all. Choosing between them is largely a matter of team philosophy — squash and merge is especially popular for guaranteeing a clean main branch regardless of development commit hygiene — and repository administrators can restrict which strategies are even available to enforce team-wide consistency.