Chapter 39: Git Rebase
Git rebase
This is the command that separates people who “just use Git” from people who understand Git and can make history look clean, professional, and easy to read years later.
Many beginners are scared of rebase because they hear horror stories:
- “I lost commits!”
- “My team hates me now!”
- “Merge conflicts everywhere!”
Today I’m going to explain git rebase very slowly, very clearly, very honestly — like I’m sitting right next to you watching the terminal and the Git graph — so that you understand exactly what happens, why people love it, when to use it, when never to use it, and how to stay safe.
1. What does git rebase actually do? (very simple mental model)
git rebase = “take all my commits and replay them on top of a different base commit”
Instead of joining two branches with a merge commit (which creates a “bubble” in the graph), rebase rewrites your branch history so it looks like you started working after the latest changes from another branch.
Before rebase:
|
0 1 2 3 4 5 6 7 8 |
A --- B --- C ← main (someone else added C) \ D --- E ← your feature branch |
After git rebase main (while on your feature branch):
|
0 1 2 3 4 5 6 7 8 |
A --- B --- C ← main \ D' --- E' ← your feature branch (new commits with new hashes) |
- The commits D and E are replayed (re-created) as D’ and E’
- They now have new commit hashes
- But they contain exactly the same changes
- The graph becomes perfectly linear — no merge bubble
Analogy most people love:
Imagine you wrote two chapters of a book while someone else was also writing.
Merge = staple your chapters at the end → book now has a little side path Rebase = you go back, copy their new chapters first, then re-type your two chapters after theirs → book reads smoothly from beginning to end as one story
2. git rebase vs git merge — the table you must memorize
| Question | git merge | git rebase |
|---|---|---|
| Creates new commit? | Usually yes (merge commit) | No — rewrites existing commits |
| History appearance | Shows parallel work + merge bubble | Looks perfectly linear |
| Commit hashes change? | No | Yes — every rebased commit gets new hash |
| Safe on shared branch (main, develop)? | Yes — recommended | No — very dangerous |
| Safe on personal/feature branch? | Yes | Yes — most common & recommended use |
| Merge conflicts | Once (at merge time) | Potentially on every commit being replayed |
| Preserves exact timeline of who did what? | Yes (honest history) | No — makes it look like you worked after others |
| Best for | Integrating finished feature into main | Cleaning personal branch before PR |
Golden rule in 2026 (almost every team agrees):
- Use merge when integrating into shared/long-lived branches (main, develop, release/*)
- Use rebase when cleaning your own short-lived feature branch before you push it or create a Pull Request
3. Realistic Example – Step by Step (copy-paste ready)
Situation You are working on a feature branch, but main received new commits while you were working. You want a clean history before creating a PR.
Step 1 – Current state
|
0 1 2 3 4 5 6 |
git lg # our pretty alias |
Something like:
|
0 1 2 3 4 5 6 7 8 9 10 11 |
* def5678 (HEAD -> feature/add-search) Add search bar JS * abc1234 Add search input HTML | * 456def7 (main, origin/main) Fix footer padding | * 789abcd Update dependencies |/ * 123abcd Initial structure |
Step 2 – Fetch latest main
|
0 1 2 3 4 5 6 |
git fetch origin |
Step 3 – Rebase your branch on top of origin/main
Make sure you are on your feature branch:
|
0 1 2 3 4 5 6 |
git switch feature/add-search |
Then:
|
0 1 2 3 4 5 6 |
git rebase origin/main |
Two possible outcomes:
A – No conflicts (clean & beautiful)
Git replays your commits:
|
0 1 2 3 4 5 6 |
Successfully rebased and updated refs/heads/feature/add-search. |
Now graph:
|
0 1 2 3 4 5 6 |
git lg |
|
0 1 2 3 4 5 6 7 8 9 10 |
* 89abcde Add search bar JS * fedcba9 Add search input HTML * 456def7 Fix footer padding * 789abcd Update dependencies * 123abcd Initial structure |
→ Perfect linear history — looks like you started working after the main updates.
B – Conflict happens (very common)
Git stops at the first conflicting commit:
|
0 1 2 3 4 5 6 7 8 |
CONFLICT (content): Merge conflict in search.js error: could not apply abc1234... Add search input HTML hint: Resolve all conflicts, then run "git rebase --continue" |
Fix conflict:
- Open conflicting file → resolve markers (<<<<<<<, =======, >>>>>>>)
- Keep the good version
- git add search.js
Then:
|
0 1 2 3 4 5 6 |
git rebase --continue |
Git moves to next commit — may conflict again → repeat until finished.
Abort if overwhelmed:
|
0 1 2 3 4 5 6 |
git rebase --abort |
→ Back to before rebase started
Step 4 – Force-push the rebased branch (only if already pushed before)
|
0 1 2 3 4 5 6 |
git push --force-with-lease origin feature/add-search |
→ –force-with-lease is safe force-push — fails if someone else pushed meanwhile
Now your PR will show clean linear history — reviewers love it.
4. Everyday rebase patterns in 2026
Most common daily flow (before PR)
|
0 1 2 3 4 5 6 7 8 9 10 |
git switch feature/add-dark-mode git fetch origin git rebase origin/main # resolve conflicts if any git push --force-with-lease |
Interactive rebase (clean multiple messy commits)
|
0 1 2 3 4 5 6 |
git rebase -i origin/main |
→ Opens editor — you can squash, reorder, edit messages, drop commits
5. When NEVER to use rebase (safety rules 2026)
- Never rebase commits that other people already pulled (main, develop, release branches) → Use git merge or git revert instead
- Never rebase public/shared history
- Never rebase after PR is created & reviewed (breaks CI checks & review comments)
6. Quick git rebase Cheat Sheet
| What you want to do | Command | Notes |
|---|---|---|
| Rebase on top of main | git rebase origin/main | Most common before PR |
| Continue after fixing conflict | git rebase –continue | After resolving one conflict |
| Abort rebase midway | git rebase –abort | Go back to before rebase started |
| Interactive rebase (squash, reorder, edit) | git rebase -i origin/main | Clean messy personal history |
| Force-push after rebase | git push –force-with-lease | Safe version of force push |
Got the rebase feeling now?
git rebase = “take my commits and replay them cleanly on top of the latest base — for beautiful linear history on personal branches”
It’s your history beautifier — use it only on your own short-lived branches before sharing.
Next?
- Want to practice interactive rebase (squash 5 commits into 1)?
- See real merge conflict during rebase?
- Or compare rebase vs merge vs revert head-to-head?
Just tell me — we’ll keep going. You’re mastering Git beautifully! 🚀
