While on the topic of git, I want to touch on the topic of merging versus rebasing.

I’ve seen a few heated discussions on this topic on social media. Some insist that merging is easier. Some that rebasing is the only way to go.

Which is it?

Well, it depends.

Case closed! LOL

But actually, before I talk about what it depends on (tomorrow…), let me offer an alternative: Neither.

Or maybe not precisely “neither”, but more like “it shouldn’t matter.” Okay, but I’m getting ahead of myself.

What am I actually talking about?

The question of merge vs rebase comes up in the context of the following situation:

You’re working on a feature branch for a few days, when you discover you’re out of sync with the main branch. Do you just merge the main branch into your feature branch and continue? Or do you rebase your feature branch on top of the new main?

So with that context in mind, how is “neither” a suitable answer?

Because feature branches are an anti-pattern^*!

Feature branches, by their very design, isolate your work from that of others. In other words, feature branches are the antithesis of continuous integration. Feature branches and continuous integration exist on opposite ends of a spectrum.

So, to resolve this merge vs rebase tension, the best solution is to stop using feature branches! Or at the very least, let your branches live for as short a time as possible (minutes, or hours at most).

^*For most projects, including your work project. Open-source projects are the main exception.