Every team has this argument. “Always merge.” “Always rebase.” “It depends.” The reason the argument never ends is that most developers don’t understand what merge and rebase actually do to their commit history. Once you see it, the right choice becomes obvious for each situation.

The setup

You have main with commits A → B → C. You created a branch feature from B and made commits D → E.

Meanwhile, someone pushed commit F to main.

main:    A → B → C → F
feature: A → B → D → E

You need to get F into your feature branch (or get your feature into main). Merge and rebase do this differently.

What merge does

git checkout feature
git merge main

Merge creates a new “merge commit” (M) that has two parents: E (your last feature commit) and F (the latest on main).

main:    A → B → C → F
feature: A → B → D → E → M
                  ↗       ↗
              C → F ------

Your commits D and E are untouched. The merge commit M ties the two histories together. The full history is preserved — you can see exactly when the branch diverged and when it was merged.

What’s in the merge commit: No code changes of its own (usually). It just records “these two lines of history came together here.” If there were conflicts, the merge commit contains the conflict resolutions.

What rebase does

git checkout feature
git rebase main

Rebase takes your commits (D and E), temporarily removes them, moves your branch to the tip of main (F), and replays your commits on top.

Before: A → B → D → E  (feature)
              → C → F  (main)

After:  A → B → C → F → D' → E'  (feature)

D’ and E’ are new commits. They have the same changes as D and E, but different hashes and different parent commits. The originals are gone (technically still in the reflog for 30 days, but not in the visible history).

The result: A perfectly linear history. It looks like you wrote your feature after F was committed, even though you didn’t.

Why this matters

Merge preserves truth

The history shows what actually happened: two people worked in parallel, and their work was combined. This is useful for debugging — you can see exactly when a change was introduced and in what context.

Rebase preserves clarity

The history is clean and linear. git log reads like a story instead of a subway map. This is useful for code review — reviewers see a logical sequence of changes without merge noise.

When to use which

Use merge when:

• Combining a long-lived feature branch into main
• You want to preserve the full history of when work happened
• Multiple people worked on the feature branch
• The branch has already been pushed and others are working on it

Use rebase when:

• Updating your local feature branch with the latest main
• Cleaning up your commit history before a pull request
• You’re the only person working on the branch
• You want a clean, linear history in the PR

Never rebase when:

• The branch has been pushed and others have based work on it
• You’re on main or a shared branch
• You don’t understand what you’re doing (merge is always safe)

The golden rule

Don’t rebase commits that exist outside your local repository.

If you’ve pushed commits and someone else might have pulled them, rebasing rewrites those commits. The other person now has commits that no longer exist in the remote. This causes merge conflicts, duplicated commits, and confused teammates.

Interactive rebase: the real power

git rebase -i HEAD~3

This opens an editor showing your last 3 commits. You can:

• pick — keep the commit as-is
• squash — combine with the previous commit
• reword — change the commit message
• drop — delete the commit entirely
• reorder — move commits up or down

This is how you turn “fix typo,” “actually fix typo,” “ok really fix it this time” into a single clean commit before opening a PR.

The team strategy that works

Most successful teams use both:

1. Rebase your feature branch onto main before opening a PR (keeps history clean)
2. Merge the PR into main with a merge commit (preserves the PR as a unit of work)

GitHub’s “Squash and merge” button does both in one step — squashes all your feature commits into one and merges it. This is the most common strategy in 2026.

The one-sentence summary

Merge combines histories and preserves truth. Rebase rewrites history for clarity. Use rebase on your local branches, merge for shared branches, and squash-merge for PRs.

FAQ

Should I merge or rebase?

Use rebase to update your local feature branch with the latest changes from main — it keeps history clean and linear. Use merge when combining a completed feature branch into main, especially if others have worked on it. Most teams rebase locally, then merge (or squash-merge) the PR.

Is rebase dangerous?

Only if you rebase commits that have already been pushed and shared with others. Rebase rewrites commit history, so if someone else has based work on those commits, it causes conflicts and duplicated commits. On local branches that only you use, rebase is perfectly safe.

When should I use rebase?

Use rebase when updating your feature branch with the latest main before opening a PR, when cleaning up messy commit history with interactive rebase (git rebase -i), and when you’re the only person working on the branch. Never rebase shared or public branches.

Related: Git cheat sheet · Git Merge Conflict — how to fix · Git Rebase Conflict — fix · Git Stash cheat sheet