Why I Use Git Rebase to Keep My Commit History Clean

I use rebase to keep my work history clean. I don't like ending up with a log that looks like this: Feature name description Fix bug query Fix bug final Fix Javier's comment Merge commit with master

Instead, I want my history to look like this: Feature name description

One commit. Clean. That's the whole point.

Git Merge

Combines two branches by creating a new "merge commit."

git checkout main
git merge feature-branch

• Keeps original commits untouched
• Safe on shared branches
• Adds extra merge commits to the log — which is exactly the noise I'm trying to avoid

Git Rebase

Takes your branch's commits and replays them on top of another branch, one by one.

git checkout feature-branch
git rebase main

• Rewrites commit history (new hashes)
• Produces a clean, linear log — no merge commits
• Never rebase a branch others are working on — it breaks their history

How I Actually Use It

If I have review comments or bugs to fix after opening a PR, I don't add new "fix" commits on top. I use rebase to go back and work directly on the commit that needs the change.

Same thing if I have, say, 10 commits and need to fix something in the 5th one — I rebase, edit that commit, and move on. No "fix bug query," no "fix Javier's comment," no trail of patches. Just the final, clean commit as if I'd gotten it right the first time.

git rebase -i HEAD~10

Mark the commit you need to fix as edit, make your change, then:

git add .
git commit --amend
git rebase --continue

Why Bother With Rebase? (Clean History)

• Easier to read git log
• Easier to use git bisect when hunting bugs
• Easier code review — one commit per logical change instead of "wip," "fix," "fix again"

Cleaning Up Commits: Interactive Rebase

git rebase -i HEAD~5

Lets you edit the last 5 commits:

• squash — merge into previous commit
• reword — change the commit message
• drop — delete a commit

Great for turning messy commits into one clean one before opening a PR.