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

#productivity #programming #git #discuss

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.

TL;DR:

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.

My take on feature branches: merge develop when needed, 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.