Lesson
Rebasing
Replay commits onto a new base for linear history — and why rewriting shared history is risky.
Learning objectives
- Explain what rebase does to commit hashes
- Compare rebase to merge
- Know when rebasing is unsafe
Replaying commits
Rebase takes your branch's commits and reapplies them one at a time on top of a new base. Because each commit's parent changes, each replayed commit gets a new hash — the originals still exist until garbage-collected.
Linear history
The result is a straight line with no merge commit, which many teams find easier to read. It is ideal for updating a private feature branch onto the latest main.
The danger
Rebasing commits that others have already based work on rewrites shared history. Their branches now disagree with yours, causing confusion and duplicate commits. Never rebase public history.
Try it yourself
Empty folder
Run git init to create a repository.
Working directory
Clean — no uncommitted changes.
Staging area
Nothing staged. Run git add.
Repository
No commits yet.
Replay the feature branch onto the latest main. Notice the new hashes.
Commands used
git switch feature
git rebase main
git log --onelineCommon mistakes
- • Rebasing a branch others have pulled.
- • Force-pushing a shared branch after rebasing.
Best practices
- • Rebase only local, unshared branches.
- • Prefer merge for integrating shared work.
Mini challenge
Rebase a feature branch onto main and confirm the history is now linear.
Open the visualizer to try itSummary
- Rebase rewrites commits with new hashes.
- It creates linear history.
- Never rebase shared commits.