git rebase vs git merge: When to Use Each

git rebase re-applies the commits from your current branch on top of another branch, effectively replaying each commit one by one rather than creating a merge commit that joins the two histories. The result is a linear commit history with no merge commits — easier to read in git log and simpler to bisect when hunting for regressions. To rebase your feature branch onto the latest main, switch to the feature branch and run git rebase main; Git will stop at each conflict so you can resolve it manually before continuing with git rebase --continue. Interactive rebase (git rebase -i HEAD~N) is even more powerful: it lets you squash, reorder, edit, or drop individual commits before they are replayed, giving you full control over the final history. The golden rule of rebasing is never to rebase commits that have already been pushed to a shared remote branch, as it rewrites commit hashes and forces all collaborators to reconcile their work.

Git FAQ

Frequently asked questions around Git and Version Control.

Using git rebase vs git merge — and When to Choose Each

git rebase is a Git command that integrates changes from one branch into another by replaying commits on a new base, resulting in a linear history without merge commits.

Using the "git merge" command is probably the easiest way to integrate changes from one branch into another. However, it's not your only option: "git rebase" offers another, slightly different way of integration.

An Example Scenario

Let's take a simple scenario with the following two branches. Our goal is to integrate "branch-B" into "branch-A":

git rebase Avoids Merge Commits

Before we look at the exact steps that occur during a rebase, let's illustrate the differences between merge and rebase.

Using "git merge", the result of our integration would look like this:

Using "git rebase", the end result looks quite different - especially because no extra merge commit will be created. Rebase results in a "straight-line" commit history:

Neither of these scenarios is "better" or "worse" than the other. It's rather a matter of taste and convention in your team!

git rebase in Slow Motion

There's quite a lot happening behind the curtains when a rebase is performed.

In step 1, Git will prepare the receiving branch, in our case "branch-A": all commits that came after the two branches' common ancestor commit (C1) will be removed - just temporarily, of course! Think of them as being parked, ready to be reapplied later.

Step 2 is very easy: Git now integrates the commits from "branch-B". At the end of this step, both branches look exactly the same.

It's the third, final step that gives "rebase" its name: the parked commits from "branch-A" are now reapplied, on top of the just integrated commits. These commits are literally re-based, their new parent commit now being C4.

Be Careful with git rebase

The rebase command is a wonderful and very powerful tool for integrating changes. Keep in mind, though, that it rewrites your commit history.

Let's revisit our above example to illustrate this: before starting the rebase, C3's parent commit was C1. After the rebase, however, C3 is now based on C4!

A revision's parent commit is crucial information. When a commit is rebased onto a new parent, it will also receive a new commit hash. This effectively makes it a completely new commit!

Trouble begins when you rebase commits that have already been published on a remote server. These commits might already be part of your colleagues' work - and should not change their identities! Therefore, please never rebase published commits!

More precisely: never rebase any branch that teammates have based their work on — even if it hasn't been officially "published" yet. When in doubt, use merge.

When to Use git rebase vs git merge

Choosing between rebase and merge comes down to whether you are working on a shared branch or a private one:

Use `git merge` when	Use `git rebase` when
Working on a shared or public branch	Cleaning up a private feature branch
You need a full audit trail of integrations	Preparing a branch before opening a pull request
Many teammates are collaborating on the same branch	Updating a local branch with the latest main
Compliance or release tracking requires an explicit integration record	You want a linear, readable commit history

When an audit trail matters, merge has a concrete advantage: every merge commit permanently records when a branch was integrated and where it came from. This can be important in regulated environments or when tracing exactly which release included a given feature. Rebase produces a cleaner linear history, but that integration event is not explicitly captured as a commit.

Using git rebase

Actually executing a rebase is dead simple. Make sure you are on the branch that should receive the changes and then simply type...

$ git rebase branch-B

Tip

Using git rebase in Tower

In case you are using the Tower Git client, the app will do the heavy lifting for you. Simply start the rebase from the toolbar:

Note

Want to Squash Commits during a Rebase?

If you want to combine multiple commits into one while rebasing, that workflow is covered in its own dedicated guide: How to Squash Commits in Git.

Handling Conflicts during Rebase: The -X Strategy Option

When a conflict arises during a rebase, Git stops and asks you to resolve it manually. You can automate conflict resolution by passing a strategy option with the -X flag:

$ git rebase -X theirs branch-B

An important detail: during a rebase, the meaning of ours and theirs is reversed compared to a normal merge:

Standard merge:
  "ours"   = current branch (HEAD)
  "theirs" = branch being merged in

During git rebase:
  "ours"   = upstream branch (the branch you rebase ONTO)  <-- reversed!
  "theirs" = your commits being replayed                    <-- reversed!

So: git rebase -X theirs branch-B
    = "keep MY changes when conflicts arise"

This means git rebase -X theirs branch-B keeps your commits' version of conflicting files — the opposite of what the name might suggest. git rebase -X ours branch-B keeps the upstream version. For the full reference on strategy options, see the official git-rebase documentation.

Note: -x (lowercase) is a completely different flag — it runs a shell command after each replayed commit (--exec). Do not confuse -x <command> with -X theirs.

Note: --preserve-merges Is Deprecated

If you encounter --preserve-merges (or -p) in older documentation or scripts, be aware that this option was removed in Git 2.34.0. Using it on a modern Git installation results in a fatal error.

Its replacement is --rebase-merges (short form: -r), which correctly recreates merge commits in the rebased history:

# Deprecated — Git 2.34+ will error:
$ git rebase --preserve-merges main

# Use instead:
$ git rebase --rebase-merges main
# or short form:
$ git rebase -r main

Learn More

Check out the chapter Rebase as an Alternative to Merge in our free online book
Understanding Rebase & Merge in Git — when to choose each strategy in a team workflow