Git Rebase

Git rebase takes the commits of one branch and replays them on top of a different base, rewriting them as new commits. The result is a straight, linear history instead of the fork-and-join shape that a merge creates.

Why it matters

Rebasing a feature branch onto the latest main keeps history clean and makes it easy to read with git log. Interactive rebase (git rebase -i) also lets you squash, reorder, reword or drop commits before sharing them. Because rebase rewrites history, the replayed commits get new hashes, so rebasing commits that others already pulled forces everyone to reconcile diverged copies. The usual rule is to rebase local, unpublished work and never shared branches.

Example

git switch feature
git fetch origin
git rebase origin/main      # replay feature commits on top of main
# resolve any conflicts, then:
git rebase --continue
git push --force-with-lease # needed because history changed

Common mistakes

• Rebasing a branch that teammates have based work on.
• Using plain --force instead of --force-with-lease, which can overwrite others' pushes.
• Fixing the same conflict repeatedly across many commits instead of squashing first.

Related

• Git branch
• Merge conflict
• Git commit
• Cherry-pick

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.