Merge vs Squash vs Rebase

The Hook (The "Byte-Sized" Intro)

When you click "Merge" on a PR, GitHub gives you three buttons: Merge, Squash, and Rebase. Most developers pick one and hope for the best. But each creates a fundamentally different commit history — and picking wrong can make your git log either beautifully clean or an unreadable mess. Here's how to choose deliberately.

📖 What is Merge vs Squash vs Rebase?

These are three strategies for integrating a feature branch into main when closing a pull request. Each produces a different commit history.

Conceptual Clarity

The three strategies:

Strategy	What Happens	Result in Main
Merge commit	All branch commits + 1 merge commit added	Full branch history preserved
Squash and merge	All branch commits combined into 1 new commit	Single clean commit
Rebase and merge	Branch commits replayed individually on main	Linear history, no merge commit

Visual comparison:

Feature branch has commits: A, B, C

─── Merge commit ───
main: ...─M (merge commit with A, B, C visible in history)

─── Squash and merge ───
main: ...─S (single commit containing all changes from A+B+C)

─── Rebase and merge ───
main: ...─A'─B'─C' (commits replayed with new hashes)

Real-Life Analogy

Merge = Publishing every draft version of your book alongside the final version. Full transparency, but noisy.
Squash = Publishing only the final version. Clean and simple, but you lose intermediate steps.
Rebase = Rewriting your drafts to look like they were written sequentially on top of the latest manuscript. Clean and detailed, but technically a rewrite.

Visual Architecture

flowchart TD PR["📋 PR Ready"] --> MERGE["Merge Commit<br/>All commits + merge commit"] PR --> SQUASH["Squash<br/>All commits → 1 commit"] PR --> REBASE["Rebase<br/>Commits replayed linearly"] style PR fill:#0f3460,stroke:#53d8fb,color:#53d8fb style MERGE fill:#1a1a2e,stroke:#e94560,color:#e94560 style SQUASH fill:#1a1a2e,stroke:#ffd700,color:#ffd700 style REBASE fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

git log readability: Squash = clean log. Merge = detailed log. Rebase = clean + detailed.
Bisect-ability: Squash makes git bisect harder (one big commit). Rebase/merge keep individual commits.
Revert-ability: Squash makes reverts easy (revert one commit). Merge/rebase may need reverting multiple.
Team alignment: Pick one strategy and stick with it — inconsistency creates a messy history.

Code

bash

# ─── Merge commit (preserves all history) ───
git switch main
git merge --no-ff feature/login
# Creates a merge commit even if fast-forward is possible

# ─── Squash and merge (combine into one) ───
git switch main
git merge --squash feature/login
git commit -m "Add login feature (#42)"
# All changes from the branch in a single commit

# ─── Rebase and merge (linear replay) ───
git switch feature/login
git rebase main
git switch main
git merge feature/login   # Fast-forward (linear)

# ─── On GitHub: choose strategy when merging PR ───
# Click "Merge pull request" dropdown:
# - "Create a merge commit"
# - "Squash and merge"
# - "Rebase and merge"

# ─── Enforce a strategy for your repo (GitHub settings) ───
# Settings → General → Pull Requests:
# ☐ Allow merge commits
# ☑ Allow squash merging
# ☐ Allow rebase merging

When to Use Each

Strategy	Best For	Avoid When
Merge commit	Preserving detailed branch history, auditing	You want a clean main log
Squash	Clean main log, simple features, WIP commits	You need to bisect individual commits
Rebase	Clean linear history with granular commits	Branch has been shared with others

Key Takeaways

Merge preserves all commits + adds a merge commit (most thorough).
Squash combines everything into one clean commit (most common for PRs).
Rebase replays commits linearly (cleanest, but rewrites hashes).
Pick a team strategy and enforce it in repo settings for consistency.

Interview Prep

Q: When would you choose squash merge over a regular merge? A: Squash merge is ideal when a feature branch has many small or WIP commits that aren't individually meaningful. It produces a single clean commit in main, making the history easier to read and reverting simpler.
Q: What is the downside of squash merging? A: You lose the individual commit history. If you need to use git bisect to find which specific change introduced a bug, all the branch's changes are in one commit, making bisect less useful within that scope.
Q: How does rebase-and-merge differ from a regular merge? A: Rebase-and-merge replays each branch commit individually on top of main, creating new commit objects with new hashes. The result is a linear history with no merge commit. Regular merge preserves the branching structure with a merge commit.