git rebase
Reapply your commits on top of another branch, creating a linear history and cleaner pull requests.
You're working on a feature branch that's gotten out of sync with main. Rather
than creating a messy merge commit, you want to replay your changes on top of
the latest code. That's when you reach for git rebase—it rewrites your
branch's history to make it look like you started working from the current state
of main.
Running git rebase main while on your feature branch takes your commits and
reapplies them one by one on top of main's latest commit. Git temporarily
removes your commits, fast-forwards your branch to match main, then replays each
of your commits in order. The result is a linear history where your feature work
appears to have been built on the current main, even though you actually started
from an older version.
The key difference from merge is that rebase changes commit SHAs—each replayed commit gets a new identifier because its parent commit changed. This rewriting of history is powerful but means you shouldn't rebase commits you've already pushed to a shared branch where others might have based work on them. Rebase is safest on feature branches that only you work on.
Interactive Rebase for History Editing
The real power of rebase comes with the interactive mode:
git rebase -i HEAD~5. This opens an editor showing your last five commits with
options to pick (keep), reword (change message), edit (modify content), squash
(combine with previous), fixup (squash without editing message), or drop
(delete). This lets you clean up your commit history before pushing or opening a
pull request.
A common workflow is making many small commits while developing ("WIP fix test," "fix typo," "actually fix test"), then using interactive rebase to squash them into coherent commits before sharing your work. Reviewers see a clean history like "Add user authentication" and "Add password reset" instead of your messy development process.
Handling Conflicts During Rebase
When rebasing, conflicts can occur if your changes and the new base both
modified the same code. Git stops and asks you to resolve conflicts just like
with merge. After fixing conflicts and staging the files, you continue with
git rebase --continue. If you get stuck or decide rebasing was a mistake,
git rebase --abort cancels the operation and returns your branch to its
original state.
In pull request workflows, rebasing before pushing creates cleaner PRs. Instead of merge commits from syncing with main, your PR shows just your feature commits in a linear sequence. Many teams prefer this because it makes code review easier and keeps the main branch history readable. After your PR is approved, the merge creates a single integration point in main's history.
Understanding rebase means understanding that it's a history rewriting tool. You're not just moving commits—you're recreating them. This creates clean, linear histories perfect for pull requests, but requires care when working with shared branches.