If you’ve ever worked on a branch while your teammates kept pushing to main, you’ve probably seen your history get messy. That’s where git rebase comes in.
What is Git Rebase?
Rebase = “take my commits and replay them on top of another branch, as if I started from there.”
Think of it like cutting commits from one place and pasting them on top of the latest main branch.
Why bother?
Keeps history linear (no merge bubbles).
Easier to read logs.
Reviewers see your work as if it came after the latest main changes.
Example
Without rebase:
main: A---B---C---F
feature: D---E
With git rebase main:
main: A---B---C---F---D'---E'
Your commits get replayed cleanly after main.
Golden rules
-> Rebase your own branch before opening a pull request.
-X Don’t rebase branches others are already using.
-> Use git pull --rebase to sync with remote without messy merge commits.
Interactive Rebase (bonus trick)
With:
git rebase -i HEAD~3
You can squash, edit, or reorder commits before sharing them.
Great for cleaning up “oops, typo fix” commits.
Visual comic
I also drew a simple comic that shows a dev literally cutting and pasting commits on top of main - it usually makes juniors go “ahh, now I get it.”
Read the full article + comic here
Question for you
Do you prefer merge commits (history preserved) or rebasing (cleaner history) in your team’s workflow?
Top comments (0)