Merge Strategies

The Hook (The "Byte-Sized" Intro)

GitHub gives you three merge buttons: Merge Commit, Squash and Merge, and Rebase and Merge. Each produces different history. Pick wrong and your git log is either a tangled mess of merge commits or a flat line with no context. Pick right and your history tells a clear story.

📖 What are Merge Strategies?

The three methods for integrating a PR's changes into the base branch, each producing different commit history.

Conceptual Clarity

The three strategies:

Strategy	History Shape	Commits	Use When
Merge commit	Branching graph	All preserved + merge commit	Large PRs needing full context
Squash and merge	Linear	All squashed into 1 commit	Small/medium PRs
Rebase and merge	Linear	All preserved (rebased)	Clean history with individual commits

What each produces:

# Merge commit:
*   Merge PR #42
|\
| * fix tests
| * add validation
| * add login form
|/
* previous commit

# Squash and merge:
* feat(auth): add login form (#42)
* previous commit

# Rebase and merge:
* fix tests
* add validation
* add login form
* previous commit

Real-Life Analogy

Merge commit = keeping all meeting notes + a summary note.
Squash = condensing all notes into one executive summary.
Rebase = inserting the notes directly into the timeline, as if they always belonged there.

Visual Architecture

flowchart TD PR["PR with 3 commits"] --> MC["Merge Commit<br/>4 commits in graph"] PR --> SM["Squash & Merge<br/>1 commit, linear"] PR --> RM["Rebase & Merge<br/>3 commits, linear"] style MC fill:#1a1a2e,stroke:#ffd700,color:#ffd700 style SM fill:#0f3460,stroke:#53d8fb,color:#53d8fb style RM fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

git log readability: Squash produces the cleanest git log.
git bisect effectiveness: Individual commits (merge/rebase) help bisect.
Revert simplicity: Squash → one commit to revert. Merge → revert the merge.
Team consistency: Pick one strategy and enforce it.

Code

bash

# ─── Configure allowed merge types (GitHub) ───
# Repository Settings → General → Pull Requests:
# ✅ Allow squash merging (recommended default)
# ⬜ Allow merge commits
# ⬜ Allow rebase merging

# ─── Default merge message for squash ───
# Set "Default commit message" to "Pull request title and description"

# ─── Merge via CLI ───
# Merge commit:
gh pr merge 42 --merge

# Squash and merge:
gh pr merge 42 --squash

# Rebase and merge:
gh pr merge 42 --rebase

# ─── Team policy example ───
# "All PRs use squash merge. Individual commits should be meaningful
#  during development but will be squashed into a single commit
#  with the PR title as the commit message."

Key Takeaways

Squash and merge is the most popular — produces clean, linear history.
Merge commit preserves full branching context (good for large PRs).
Rebase and merge gives linear history with individual commits.
Pick one strategy and enforce it for consistency.

Interview Prep

Q: What are the three PR merge strategies? A: Merge commit (preserves all commits + adds a merge commit), squash and merge (condenses all commits into one), and rebase and merge (replays commits linearly on the base branch).
Q: When would you choose squash merge over merge commit? A: Squash merge for most PRs — it gives a clean, linear history where each merge is one commit with a descriptive message. Use merge commits for large PRs where individual commit history provides valuable context.
Q: How does the merge strategy affect git bisect? A: Squash merge limits bisect to finding which PR introduced a bug. Merge commit and rebase preserve individual commits, allowing bisect to find the exact commit within a PR.