Your Git History Is a Crime Scene -Git Rebase Is the Cleanup Crew

Giannis Papachristou — Software Engineer / Tech Ambassador @Code.Hub

You join a new project — thousands of commits in dozens of branches. Hundreds of developers have touched the code before you, most of them long gone. And there is no context or handover, just history.

So you start digging. You search by ticket ID, following the commit history. You try to understand how things evolved. And then you see the git log.

It looks more like spaghetti bolognese than a system designed by engineers to track the sequence of decisions. It looks like a crime scene.

Commits scattered everywhere: “fix”, “final fix”, “merge develop”, “resolve conflict”… repeated like a ritual.

Somewhere in there is the actual logic. Good luck finding it.

At some point, you stop reading commits and start guessing intentions (which is always a great sign in software engineering). Sounds familiar?

What Went Wrong

That “crime scene” doesn’t just happen.

It’s a series of completely normal, everyday habits that slowly destroy history (I’ve been guilty of all of them).

Treating merge like a safe default

You want to bring updates from develop into your feature branch, so you do the obvious thing:

git fetch origin develop

git merge origin/develop

It works with no complaints or scary warnings. So you do it again, and again, and again.

Before you know it, your branch history looks like a tangled web of merge commits, conflict resolutions and unrelated changes mixed together.

Stacking commits instead of refining them

You implement part of a feature, then you improve it, then you fix a PR comment. Each step becomes a new commit:

add validation
fix validation
improve validation
actually fix validation

Technically correct but practically useless. All of these could have been one clean, meaningful commit.

But instead of refining your work, you just keep stacking changes on top of each other like nothing will ever need to be reviewed or understood again.

Fear of rewriting history

Most developers have heard some version of:

Don’t mess with Git history

So they don’t. They avoid rebasing, amending commits and cleaning things up. Because it feels dangerous. And to be fair, it can be… if you don’t know what you’re doing.

So the safer option becomes “Just leave it as it is”.

What Rebase Actually Does

Rebase has a reputation for being complicated, mostly because it’s explained in the most complicated way possible. Here’s the simple version:

Rebase doesn’t change your work. It changes how your work story is told.

Instead of keeping every step exactly as it happened, rebase lets you:

• replay your commits on top of a new base (e.g. latest develop)
• clean up unnecessary steps
• combine related changes into meaningful units

The result?

A linear history that actually makes sense to someone who wasn’t inside your head while you were coding. Same code, much better story.

How to Use Rebase in Real Life

The goal

Before opening a PR, your branch should be

• up to date with develop
• clean (no junk commits)
• easy to review

Not historically accurate, as no reviewer cares about your thought process.

Step 1 — Get the latest changes

git fetch origin

You shouldn’t work on stale branches unless you enjoy resolving conflicts later.

Step 2 — Rebase on top of develop

git rebase origin/develop

This moves your work on top of the latest code, instead of merging it in. So instead of creating noise, you stay linear.

Step 3 — Clean up your commits

git rebase -i origin/develop --autosquash

This is where you combine related commits, fix commit messages and remove useless steps. Turn this:

add code
fix comment
fix again
add tests

Into:

add feature with edge case handling

One commit with one idea. And one less headache for your reviewer.

Step 4 — Push

git push --force-with-lease

Yes, with force. This is the part that scares people and it shouldn’t.

You’re rewriting your own branch, not shared history.

That’s exactly what rebase is for.

Why this workflow actually matters

Your PR becomes easier to review, your changes are easier to cherry-pick (hotfixes, testing environments, etc.) and your history becomes useful instead of decorative.

Your work is now portable and understandable.

Even if your company enforces completing PRs with merge commits, rebasing your branch into a clean state before the PR is a good practice that eliminates most of the mess.

Common Fears

Let’s not pretend rebase isn’t scary at first. Yes, you can mess things up. But most fears come from not knowing one simple thing:

Almost everything in Git is recoverable

“What if I lose my changes?”

You won’t. Not unless you are actively trying to. Even if you mess up a rebase, Git keeps track of where you were.

You can always go back using:

git reflog

This shows every move your branch made. Then:

git reset --hard <commit>

And you’re back to safety. So no, your work isn’t going to disappear. Git is here to support you.

“What if I break something and don’t know how to fix it?”

You will. That’s part of the deal.

When rebase pauses on conflicts, it can be confusing and make you question your life choices. But it also gives you control. Once you resolve all conflicts:

git rebase --continue

Did you mess up?

git rebase --abort

That last one literally says “Never mind, take me back to safety”.

“What if I mess up history or other people’s work?”

That only happens if you rebase shared branches. So don’t.

Simple rule:

Rebase only your own feature branches

Don’t rebase branches other people are using or you will end up in “quick” 1 hour calls to resolve the mess you created.

At some point, every codebase starts to look messy. That’s normal. What’s not normal is accepting it. Rebase won’t magically fix everything, but it gives you control over how your work is presented, understood, and maintained.

And in a repository full of noise, be the person who leaves things cleaner than before.