git rebase
Replaying commits onto a new base.
Rebase is an alternative to merge. Instead of creating a merge commit that joins two diverged histories, rebase movesyour branch's commits to start from the tip of another branch — replaying each commit one by one on the new base. The result is a perfectly linear history, as if you had written the commits there originally.
Watch the Replay
Step through each phase. Pay attention to the commit hashes — D′ and E′ have different hashes from D and E even though they introduce the same changes.
main has moved to C. feature has D and E. Running git rebase main will replay feature's commits onto the tip of main.New Commits, Same Changes
A commit object's hash is computed from its content plus its parent hash. When rebase replays D onto C instead of B, the parent changes — so the SHA-1 changes. D and D′ apply the exact same diff but are completely different objects in .git/objects/.
This is why the golden rule of rebase is: never rebase commits that have already been pushed and shared with others.
Rebase vs Merge
Both integrate changes. The difference is in the history they produce:
- mergepreserves the exact sequence of events, with a merge commit as a record of the integration. History is truthful but can look messy.
- rebaserewrites history to look like you always worked on top of the target branch. History is clean but less literal.
Rebase Conflicts
Rebase can hit conflicts too — one per replayed commit instead of once at the end. If commit D conflicts, Git pauses, lets you resolve it, and then you run git rebase --continue to replay the next commit.
Use git rebase --abort at any point to cancel and return to the pre-rebase state.
The Commands
The typical workflow: rebase your feature branch onto main to keep it up to date, then fast-forward merge when it's ready — resulting in a perfectly linear history with no merge commits.