Rebase: replaying commits
Move your work onto a new starting point for a straight-line history.
1 Learn the idea
Merge ties two histories together with a merge commit. Rebase takes another approach: it takes your commits and replays them, one by one, on top of another branch — as if you had started your work from there.
What actually happens
- Git finds the commits on your branch that are not on the target (e.g.
main). - It moves to the tip of the target and re-applies each commit as a new commit.
- Finally it moves your branch pointer to the last new commit.
- The old commits are left behind, unreferenced (they fade out of view but can be recovered via the reflog).
2 Watch it happen
Press Play or use → to step through. Watch the graph as each command runs.
Read this demo as text
$ git switch feature
featurebranched off beforemaingotMain moves on. The histories have diverged.$ git log --oneline --all
Note the hashes of the two feature commits. They are about to be replaced.
$ git rebase main
Rebase replays both feature commits on top of
main. They get new hashes. The originals are faded — orphaned, no branch points to them anymore.$ git log --oneline
A perfectly linear history: Initial → Main moves on → Feature part 1 → Feature part 2. No merge commit.
$ git switch main
Back to
main. Sincefeaturenow sits directly on top ofmain…$ git merge feature
…merging is a clean fast-forward. This rebase-then-fast-forward flow is how many teams keep history straight.
$ git branch -d feature
Done. History reads like the work happened in a single line.
- Keeps history exactly as it happened
- Adds a merge commit with two parents
- Never rewrites existing commits — always safe
- History can look like a subway map
- Rewrites your commits onto a new base
- No merge commit — straight line
- Creates new hashes — only for unshared work
- Easier to read,
git logtells a clean story
Rebase conflicts
Because commits are replayed one at a time, a conflict can stop the rebase mid-way. Resolve it just like a merge conflict — edit the file, git add — but then run git rebase --continue (not commit). Want out? git rebase --abort returns everything to how it was.
git rebase <branch>Replay current branch on top of <branch>git rebase --continueContinue after resolving a conflictgit rebase --abortCancel and restore the original branchgit pull --rebaseUpdate from remote without merge commits3 Check your understanding
After git rebase main, do your feature commits keep their hashes?
You are on feature in this graph and run git rebase main. What does the result look like?
Which situation breaks the golden rule of rebasing?
A rebase stops with a conflict. You fix the file. Next?
4 Practice for real
Rebase through a conflict
You are on feature. Rebase it onto main so the history is linear. One commit will conflict on app.txt — resolve it (any content without markers) and finish the rebase.