🔀 Git Rebase

"Git is easy," they said. "Just rebase it," they said.
Next thing I know, I’m rewriting history like a time-traveling developer with commitment issues.


This is a story about how I went from:


git pull origin main
Auto-merging package.json
CONFLICT (content): Merge conflict in package.json


To:

git rebase -i HEAD~5
# pick, squash, fixup — let's go!


And actually understood what I was doing.


🤯 At First, There Was Fear

My early Git strategy was simple:

  • git add .
  • git commit -m "something"
  • git push origin HEAD

Conflicts? I'd stare at them like they were encrypted messages from an ancient civilization.

Rebase? That was black magic. Something senior devs did to look cool in front of the juniors.


🛠️ Why I Decided to Learn Rebase

There was a day when I made 12 tiny commits like this:


fix typo
oops fix again
console.log removed
better fix
final final fix
seriously final


When I opened a PR, my teammate commented:

"Can you clean up the commit history?"

I panicked. Googled "clean up git history without destroying the world".

Discovered git rebase -i. And the rabbit hole opened.


🧪 The First Attempt

bash

Copy

Edit
git rebase -i HEAD~12


Boom. A text editor popped up with lines like:


pick a1b2c3 fix typo
pick d4e5f6 oops fix again
pick f7g8h9 better fix


Me: Okay, what’s “squash”?

Google: "Combines this commit with the previous one."

Me: Clicks every line like I’m playing Jenga with my repo.

Eventually:

  • I squashed related commits into one.
  • Wrote a clean commit message.
  • Saved and closed the editor.

Git:

Rebase successful.

Me:

"Wait… it worked?"


💡 What I Learned


  1. Rebase rewrites history (but in a good way).
  • Your branch becomes like it always had those clean commits.
  • But don't rebase public branches that others are working on unless you want Slack to explode.
  1. Interactive rebase (-i) is your best friend.
  • pick, squash, fixup, edit — powerful tools in your Git toolbox.
  • It’s like git surgery. Delicate, but satisfying.
  1. Conflicts during rebase are normal.
  • Just resolve them (git status will guide you), then:


git add .
git rebase --continue
  • Rinse, repeat, emerge stronger.


  1. Aliases help.
  • I now use:
git config --global alias.ri 'rebase -i'
  • So I can do


git ri HEAD~5


😅 Fun (Painful) Mistakes I Made

  • Rebasing after pushing and breaking the whole team’s history.
  • (Never again. Sorry, Muhammadqodir.)
  • Using rebase --abort so often I started typing it in my sleep.
  • Accidentally squashing commits that had unrelated changes, then having to untangle them like Git spaghetti.


🧘‍♂️ Rebase Zen: When to Use It

  • ✅ Cleaning up your local commit history before a PR
  • ✅ Squashing “work in progress” commits into logical units
  • ✅ Rebasing feature branches onto updated main
  • ❌ Rewriting shared history (unless you enjoy chaos)


🎯 TL;DR

  • git rebase is scary… until you understand it.
  • It's surgical history editing, not destruction.
  • Use it before opening a PR — your teammates will love you.
  • Read the conflicts carefully, and don’t panic.
  • You will mess up. That’s part of the learning.



👋 Parting Words

Learning rebase felt like learning to play a complicated instrument.

At first it was noise. But then I hit my first clean PR with just two commits:


feat: add notification model
chore: refactor message service


And it felt beautiful.

If you're scared of rebase — you're not alone. But you’re also missing out.

Try it. Break it. Fix it. Learn it.

Or you’ll be stuck with commit messages like:



fixed stuff again lol



Forever.

— Olloyor