Git rebase vs merge | SubjectVision

Start with the decision that actually matters

Both commands can integrate one line of Git history with another, but they preserve different truths. Merge preserves the fact that two lines of work existed. Rebase rewrites one line so it appears to have started from a newer base. The right choice depends less on aesthetics than on whether the commits are private, shared, and historically meaningful.

Before you choose a command

Are you preparing your own unpublished work, or integrating history that other people may already depend on?

Why this question comes first

Because rewriting private commits and rewriting shared commits have completely different collaboration consequences. The graph shape is secondary to who already depends on those commit IDs.

See the commit graphs before comparing commands

Suppose main advanced to C while your feature branch added D → E from B.

Before integration

A---B---C  main
     \
      D---E  feature

Merge

A---B---C------M
     \        /
      D------E

Rebase feature onto main

A---B---C---D'---E'
                feature

The merge keeps D and E and records the integration in M. The rebase creates new commits D′ and E′ because their parent chain changes. That difference explains most of the safety trade-offs below.

Side-by-side trade-offs

Decision dimension	git rebase	git merge	How to decide
Commit identity	Replays commits onto a new parent chain, creating new commit IDs.	Keeps existing commits and usually adds a merge commit when histories diverge.	If preserving existing commit identities matters, merge is the safer default.
History shape	Produces a linear-looking branch history after the replay.	Preserves branch topology, including where lines of work diverged and later joined.	Choose based on whether the branch relationship itself carries useful history.
Shared history safety	Can disrupt collaborators if you rewrite commits they already pulled or based work on.	Usually integrates shared published history without changing existing commit IDs.	For shared branches, prefer merge unless the team has an explicit coordinated rebase policy.
Conflict experience	May stop repeatedly while replaying individual commits, so the same conceptual conflict can surface more than once.	Typically resolves the integration at the merge point, combining the branch tips in one operation.	Repeated rebase conflicts can be useful when preserving each commit matters, but merge can be simpler when integrating a completed shared branch.
Review preparation	Useful for cleaning local commits, squashing fixups, and placing a private feature on the latest base before review.	Useful when the team wants the review branch topology preserved exactly as it happened.	Rebase is strongest as a private-history preparation tool, not as a universal team-history rule.
Audit/story value	Can hide the original branch point and rewrite the sequence in which local commits originally existed.	Retains the historical fact that independent lines of development were integrated.	When topology helps explain releases, hotfixes, or parallel work, merge often tells the more truthful story.

Work through realistic situations

Instead of memorizing “rebase for clean history” and “merge for safety,” practice identifying what is true about the branch first.

Scenario 1

You have a private feature branch and main moved forward

Situation: Your branch has three commits, nobody else has pulled it, and you want to test those changes on top of the latest main before opening a pull request.

Recommendation: Usually rebase onto the updated remote-tracking main branch.

Reasoning: The commits are still private, so rewriting their IDs does not invalidate anyone else’s work. Fetch first, inspect the graph, then rebase onto the exact remote state you intend to use.

Scenario 2

A team branch is already shared by several developers

Situation: Several people have pulled the branch and created work from its existing commits. You now need to integrate the latest main.

Recommendation: Usually merge main into the shared branch, or follow the team’s established integration policy.

Reasoning: Rebasing published commits would replace commit IDs that collaborators may already reference. A merge integrates the new history without pretending the old shared commits never existed.

Scenario 3

You are cleaning fixup commits before review

Situation: Your local branch contains “fix typo”, “address review note”, and “oops tests” commits that are not useful as permanent review units.

Recommendation: Interactive rebase can be appropriate before publishing or while the branch is still safely owned by you.

Reasoning: Here rewriting is the point: you are deliberately improving the logical commit sequence. The safety condition is that no collaborator depends on the old IDs.

Scenario 4

You are integrating a release branch with meaningful parallel history

Situation: A release branch and main each contain important work, and future engineers may need to see that the release line existed independently.

Recommendation: Merge is often the better historical record.

Reasoning: A merge commit can document the integration point and preserve both parent lines. Flattening that topology may make the graph prettier while removing useful operational context.

A practical decision checklist

If the commits are private and you are preparing your own branch, rebase is often reasonable.
If other people may depend on the existing commit IDs, prefer merge unless everyone is coordinating the rewrite.
If branch topology explains something important about releases, hotfixes, or parallel work, preserve it with merge.
If you cannot draw the before-and-after commit graph, inspect first rather than choosing by habit.
Do not use conflict count as the only decision criterion; choose the history model first, then resolve conflicts deliberately.

Quick check

A teammate has already based new commits on your branch. You prefer a linear graph. Is that preference alone enough reason to rebase the shared commits?

Reveal the reasoning

No. Once collaborators depend on the existing IDs, rewriting the branch creates coordination cost. A linear graph is not worth silently invalidating shared history. Use the team’s agreed workflow; merge is the safer default when no coordinated rewrite exists.

Common comparison mistakes

“Rebase is always cleaner, therefore always better”

Linear history is a presentation property, not automatically a correctness or collaboration benefit. A clean-looking graph can conceal meaningful branch topology or force teammates to reconcile rewritten commits.

“Merge is outdated because it creates extra commits”

A merge commit can carry real information: two histories existed and were intentionally integrated at this point. Removing that fact is not automatically an improvement.

Choosing a strategy before checking who owns the commits

The most important safety question is whether the commits are private or already shared. The same rebase that is harmless on your unpublished branch can be disruptive on a team branch.

Treating a successful Git operation as proof the code is correct

Git can complete a merge or rebase while your conflict resolution subtly changes behavior. Run focused tests and inspect the resulting diff; version-control success is not application correctness.

Guided practice

You have a private feature branch with two commits. Nobody has pulled it. origin/main advanced by three commits. You want to test your work on the latest main and present a simple review history. Which integration approach is reasonable, and what should you do before running it?

Hint

First update your knowledge of the remote and inspect the graph. Then decide whether rewriting is safe based on branch ownership.

Tutor answer

A rebase is reasonable because the feature commits are still private. Run git fetch origin, inspect git log --graph --oneline --decorate --all, then rebase onto origin/main. Afterward, run relevant tests because a conflict-free replay does not prove behavior is unchanged.

Independent practice

Create a disposable repository and build the same divergent history twice. In one copy, merge; in the other, rebase. Inspect both graphs and write down which commit IDs survived, what new commits appeared, and what historical fact each graph preserves or hides. Then intentionally create a conflict and compare how the two operations present it.

Continue from the decision into action

Frequently asked questions

Should I rebase before every pull request?

Not automatically. Rebasing a private branch before review can be useful when your team values a linear base or clean logical commits, but repositories differ. Follow the collaboration policy and avoid rewriting commits others already use.

Does rebase lose commits?

A normal successful rebase replaces the replayed commits with new commits carrying equivalent changes. The old commits may remain reachable through the reflog for a while, but their IDs are no longer the branch’s current history.

Does merge always create a merge commit?

No. If the current branch can move directly to the other tip without divergence, Git can fast-forward. When both sides have unique commits, a normal merge typically creates a commit with two parents unless a different strategy is requested.

Which causes fewer conflicts?

There is no universal winner. Merge often presents the final integration conflict once, while rebase may surface conflicts commit by commit. The total difficulty depends on how the branches changed, not just the command name.

Learner recap

The safest choice starts with ownership of history.

Rebase is powerful when you deliberately rewrite private work. Merge is powerful when you need to preserve existing commits and the fact that independent histories were integrated. Do not choose by graph aesthetics alone: inspect the history, identify who depends on it, predict the resulting graph, then verify the code after integration.

Review git rebase in depth

Git rebase vs merge: choose by history ownership, not habit