Engineering Craft › Version Control (Git)

Rebase

Replaying commits on top of another base for a linear history.

Also known as: git rebase, rebasing

git rebase takes the commits on your branch and replays them on top of a different starting point, usually the latest main. The result is a straight line of history.

Before:        A --- B --- C          (main)
                      \
                       D --- E        (feature)

After rebase:  A --- B --- C          (main)
                            \
                             D' --- E'   (feature)

git switch feature
git rebase main

D' and E' have the same changes as D and E, but they’re new commits with new hashes, because their parent changed. That’s why rebase counts as rewriting history.

Handling conflicts

Git replays commits one at a time, so you might resolve a conflict per commit:

# fix the files, then
git add <files>
git rebase --continue
# or give up and return to how things were:
git rebase --abort

The golden rule

Don’t rebase commits other people already have. If you rebase a shared branch, their history and yours no longer match and they have to untangle it. Rebase your own, unshared work; after rebasing a branch you’ve already pushed, update it with git push --force-with-lease (see force push).

Rebase or merge?

Rebase gives a cleaner, linear history. Merge keeps the true history and never rewrites anything. Many teams rebase their feature branch onto main before merging, then merge normally. For the trade-offs see merge vs rebase.

git rebase -i lets you reorder, edit or squash commits (see interactive rebase).