Stop Rebasing Everything: Your Git History Isn’t That Special

At my company, the default Git strategy for every branch, even feature branches, is to rebase. It’s part of the official workflow, and people treat it almost like a sacred ritual.

---

Let’s be honest: rebase is overrated. Every time someone insists that I should rebase my feature branch before merging, I just want to roll my eyes. Why? Because in most modern workflows, feature branches get squashed into a single commit when they’re merged anyway.

So let’s think about it for a second. If the entire (and often messy) history of your branch ends up collapsed into one clean commit at the end, why bother struggling with a rebase just to keep that temporary history “clean”?

On paper, rebase sounds great: a nice linear history, no ugly merge commits, blah blah. But in practice, it’s one of the trickiest and most error-prone Git operations out there. One wrong move, and you’re force-pushing your branch, breaking your teammates’ clones, or losing commits in a botched interactive rebase.

Meanwhile, merge does the job just fine. You pull, resolve a conflict or two if needed, and move on with your life. The history stays transparent (you can see what really happened) and nobody wastes time doing Git gymnastics just for the flex.

So yeah, unless you’re building a museum exhibit around your Git history, skip the rebase, especially on feature branches!

Merge, resolve your conflicts once, and ship your code. What matters is the result, not the commit history of a branch that’s going to be squashed anyway.

---

So here’s my take: Rebasing feature branches is often a waste of time if your team squashes them on merge. In that case, rebase only adds complexity, risk (force-pushes, lost commits), and repeated conflict resolution for little to no real benefit.

Merge develop when you need to grab its latest changes, resolve conflicts once, and move on.

Rebasing can still make sense for other types of branches like long-lived integration branches, or release branches. That’s a different discussion to have.

Comments

[𒎏Wii 🏳️‍⚧️]

I have two rather strong opinions on feature branches, and those are:

Don't squash branches. Ever. Use git rebase --interactive to clean up your branch if you must; remove commets that get reverted within the same branch, remove typos from the history, etc. If you're alone, do this as you're working on the branch. Then merge it with its proper development history.

Always use merge commits. Once a project reaches 1.0, all feature branches should be properly merged. Merge commits are a great place to put high-level information about what a branch does and why, and they provide natural grouping to your branches commits.

The one thing I'm a bit more on the fence about is rebasing branches on HEAD before merging them, to avoid parallel branches. Leaning towards not doing that though.

[Guillaume]

I tend to agree with you. But, during my career, I discovered that:

• most people don't really master git, they usually knows about commit and push and that's it,
• many of them don't really want to learn, as Git can be perceived as scary or very complicated (and, to be fair, the learning curve is no joke),

When thousands of devs work in a company, coherence accross projects and codebases in git usage is also an important :)
Basically company have to choose between coherence across project, and freedom for each team to define its own practices.

My company choose coherence 🥲

[𒎏Wii 🏳️‍⚧️]

Mastering git is definitely a lot of work, but using rebase to clean up branches is almost the same every time: you run git rebase --interactive main (or whichever branch yours is based on), then look at your commit messages and figure out if anything can be combined, removed, reworded, etc.

Fully re-arranging branches isn't usually needed and if it is, there should generally be someone who can assist with it. At least ideally.

[david duymelinck]

I came for the click bait title, but I stayed for the nuanced conclusion.

[Guillaume]

Haha yeah indeed, I was looking for a catchy title, I might’ve gone a bit overboard 😬

[MikeBot]

I think people often forget what the actual purpose of rebase is.
It’s not about having a perfectly clean history — it’s about changing the base of a branch.
For example, if I have a feature branch in PR and I want to start another feature that depends on it, I branch off (base) from that one.
When the first feature gets merged into develop, I just rebase the second one onto develop to keep the chain consistent.
That’s the kind of scenario rebase was originally meant for.