Before comparing the three options, let’s establish exactly what situation they’re all solving.

The Simple Setup

Picture a feature branch with several commits on it — maybe a first attempt, a fix for a typo, another fix for a bug the first attempt introduced, and a final polish commit. When that branch’s pull request is approved and ready to join the main branch, GitHub offers three fundamentally different ways to actually perform that merge, each producing a noticeably different-looking final history on the main branch.

The default, most traditional of the three options, and the one that changes the least about your original history.

What It Does

A Merge Commit brings every single commit from the feature branch onto main exactly as they were written, and adds one additional new commit on top — the merge commit itself — which has two parents, recording precisely where these two lines of history rejoined. Nothing from the feature branch is altered, combined, or discarded; it’s all preserved, plus one extra commit marking the join.

graph LR
    A[main] --> B[main continues]
    A --> C[commit 1 on feature]
    C --> D[commit 2 on feature]
    D --> E[commit 3 on feature]
    B --> F[Merge Commit]
    E --> F
        

The option that most aggressively simplifies history, trading detail for a clean, single summary.

What It Does

Squash and Merge takes every commit on the feature branch, combines their changes together, and creates exactly one brand-new commit on main containing all of that work at once. The individual, step-by-step commits from the feature branch — the typo fixes, the false starts, the intermediate attempts — are not preserved on main at all; only their final, combined result is.

graph LR
    A[main] --> B["One new squashed commit - all changes combined"]
    B --> C[main continues]
        

The middle ground between the other two — it keeps individual commits, but reshapes exactly where they sit in history.

What It Does

Rebase and Merge takes each individual commit from the feature branch and replays them, one at a time and in their original order, directly onto the tip of main — as if you had written each of those commits on main all along. Unlike Merge Commit, no separate merge commit is created; the result is one single, perfectly straight line of history. Unlike Squash and Merge, each original commit still exists individually, just relocated.

graph LR
    A[main] --> B["commit 1 replayed onto main"]
    B --> C["commit 2 replayed onto main"]
    C --> D["commit 3 replayed onto main"]
    D --> E[main continues]
        

With all three explained individually, let’s line them up directly against each other.

The real-world impact of this choice becomes most visible once you zoom out and look at months of accumulated history.

A project that consistently uses Merge Commit ends up with a visibly branching, tree-like history graph, where you can trace exactly which commits belonged to which pull request by following the branching and rejoining pattern. A project using Squash and Merge instead ends up with a clean, straight sequence of commits on main, where each one represents an entire completed pull request — extremely easy to skim, but with no visibility into how that feature was actually built internally. A project using Rebase and Merge also ends up with a straight line, but one made of many smaller, individual commits, giving a more granular — though sometimes noisier — record of exactly how each feature evolved.

Let’s break down the genuine pros and cons of all three, side by side.

Over years of teams using all three options, some clear patterns of good and poor usage have emerged.

The choice of merge strategy can genuinely matter for compliance and audit purposes, beyond just readability preferences.

A practical checklist for choosing and sticking with a merge strategy across a team.

Each of the three options has genuine, common real-world adoption across very different kinds of teams and projects.

No — all three options result in exactly the same final code on main. The only difference is how that history is structured and recorded.

Yes — GitHub allows repository administrators to enable or disable each of the three merge strategies individually in the repository’s settings.

Not immediately — they remain visible on the original feature branch and in the pull request’s history until that branch is deleted, though they no longer exist individually on main.

Merge Commit has traditionally been the original, default behavior, though many repositories today configure a different default, or offer all three, depending on the team’s preference.

Yes — if any individual commit can’t be applied cleanly onto the current state of main, the same kind of conflict resolution used in a regular rebase is required before the merge can complete.

No — each one serves a genuinely different goal for how a team wants its history to look, and the right choice depends entirely on what that team values most: full detail, clean simplicity, or a straight line.

GitHub’s three pull request merge strategies — Merge Commit, Squash and Merge, and Rebase and Merge — all achieve the same underlying goal of bringing a feature branch’s code onto main, but they produce meaningfully different commit histories in the process. Merge Commit preserves everything exactly as written, plus a marker of where the branches rejoined. Squash and Merge collapses everything into one clean, single commit. Rebase and Merge keeps each individual commit but arranges them into a perfectly straight line with no merge commit at all. Choosing between them is really a choice about what a team values most in its shared history — completeness, simplicity, or linearity — and the right answer depends entirely on that team’s own priorities.