Workflows

Rebase or merge? When to use which

Both bring the same changes together, only the shape of the history differs. When to rebase, when to merge, and the one rule you should never break.

Rebase or merge? When to use which

Two ways to combine work

Merge and rebase solve the same basic task: you want to bring the changes from one branch together with another. They just do it in different ways, and that determines when each fits. There is no blanket right or wrong, only a question of context and team rules.

What a merge does

A merge takes two lines of development and joins them with a new merge commit. The history stays the way it actually happened, with branches and joins. That is honest and traceable, but it can look cluttered with many branches.

What a rebase does

A rebase replays your commits onto the tip of another branch, as if you had worked there from the start. The result is a straight, linear history without merge commits. It reads cleanly but rewrites history, because the commits get new identities.

The most important rule

Do not rebase commits you have already shared. As long as your commits are only local, you can rebase them safely. Once others might have them, a rebase would change the shared history under their feet and cause chaos. For already shared work, merge is the safe way.

When each fits

  • Rebase for your local, not yet shared work, to tidy it into a clean, linear shape before sharing.
  • Merge to combine shared branches and preserve the real history.
  • Many teams combine both: rebase locally to tidy up, then merge into the main branch.

A common misunderstanding

Rebase does not make your code better and merge does not make it worse. Both bring the same changes together in the end. The difference lies only in the shape of the history. Keeping that in mind lets you decide calmly rather than by gut feeling.

How Spire helps

Spire shows the history clearly, so you can see what a merge or rebase actually does, before and after you run it. Conflicts, which can occur with either, are kept as a calm, structured list. And because many steps have a visible undo, you can try a combination without fear of destroying anything.

In short

  • Merge preserves the real, branching history.
  • Rebase creates a straight, linear history but rewrites it.
  • Never rebase shared commits.
  • The difference is the shape, not the result.

Try Spire on your own repositories.

Free for 30 days, no account, no credit card. The native Git client you own instead of rent.