Rebase

Pronunciation: REE-bays

Updated September 29, 20262 min read

In short

A rebase in Git replays a branch's commits on top of another commit, rewriting history to produce a cleaner, linear sequence of changes without merge commits.

What is a rebase in Git?

Rebasing takes the commits from your branch and reapplies them, one by one, on top of a different starting point, usually the latest commit on main. The result looks as if you had started your work from the newest version of the code. Because the commits are reapplied, Git creates new commits with new hashes, even when their content is the same.

Imagine you started writing a chapter based on an old draft of a book, and meanwhile the book was updated. Rebasing is like rewriting your chapter so it builds on the newest draft, as though you had started from it all along. Developers use rebase to keep feature branches up to date and to keep a straight, easy-to-read history without extra merge commits.

Interactive rebase, started with git rebase -i, lets you edit history before sharing it. You can reorder commits, combine several small commits into one (called squashing), reword commit messages, or drop commits entirely. It is a common way to tidy up a branch before opening a pull request.

The golden rule of rebasing is to never rebase commits that other people have already pulled. Since a rebase replaces commits with new ones, collaborators end up with a history that no longer matches yours, which causes confusion and duplicate work. When you rebase your own branch after pushing it, update the remote with git push --force-with-lease, which refuses to overwrite commits you haven't seen.

At a glance

Rebasing rewrites the branch as if it had started from the newest main. The replayed commits get new hashes.

Key takeaways

Rebase replays your commits on top of another branch or commit.
It creates a linear history with no merge commits.
Rebased commits are new commits with new hashes.
Interactive rebase (git rebase -i) can reorder, squash, reword, or drop commits.
Never rebase commits that others have already built on.

Example

Rebasing a feature branch onto mainbash

# Update your feature branch with the latest main
git switch feature/search-bar
git fetch origin
git rebase origin/main

# If a conflict appears: fix the files, then continue
git add src/search.ts
git rebase --continue   # or: git rebase --abort to cancel

# Tidy up the last 3 commits (squash, reword, reorder)
git rebase -i HEAD~3

# Update the remote branch safely after rewriting history
git push --force-with-lease

Readers ask

What is the difference between git merge and git rebase?

Both integrate changes from one branch into another. Merge preserves history and may add a merge commit, while rebase rewrites your commits on top of the other branch to create a linear history.

When should I not use rebase?

Avoid rebasing commits that are already on a shared branch others work from, such as main. Rewriting them forces everyone else to reconcile their copies, which can lead to lost or duplicated work.

What does git pull --rebase do?

It fetches new commits from the remote and then rebases your local commits on top of them, instead of creating a merge commit. This keeps your branch history linear when syncing with teammates.

Often compared

Git Merge vs RebaseGit merge joins two branches with a merge commit that keeps the full history, while git rebase replays your commits onto another branch for a linear history.

Sources

Git documentation: git-rebasegit-scm.com(opens in a new tab)

Spotted a mistake or something missing on this page?Suggest an edit