Day 09/13 of Git 101 Series
REBASE
Concept Explanation
Rebase replays your commits onto another commit.
Instead of joining histories, it rebuilds your branch so it begins at a different base.
Each commit is recreated with a new parent, which means commit IDs change.
Rebase rewrites history.
Commands
git checkout feature
git rebase main # move feature on top of main
git rebase -i HEAD~5 # clean up commit history
git rebase --continue
git rebase --skip
git rebase --abort
Strong Example
History:
main: A — B — E
feature: \ C — D
Running:
git checkout feature
git rebase main
Git identifies commits unique to feature (C, D) and replays them on top of E.
Resulting history:
A — B — E — C' — D'
C' and D' are new commits with new SHAs.
The graph becomes linear.
Real World Use Case
Before submitting a feature for review, a developer cleans the commit history.
Small WIP commits are squashed, messages are refined, and ordering is fixed.
Rebasing onto the latest main ensures reviewers see a clean, linear diff without noisy merge commits.
Teams with strict linear-history rules require this.
Underhood Explanation
Rebase internally uses cherry-pick.
Steps:
- Find merge base of feature and main.
- Collect commits reachable from feature but not main.
- Recreate each commit with the same diff but a new parent (top of main).
- Move the feature pointer to the last recreated commit.
Because commit IDs depend on parent, tree state, and metadata, rewritten commits get new SHAs.
This is why rebasing public branches breaks collaborators’ histories.