Git, rebase vs merge

One of the tweets you can post to get engagement is “do you use merge or rebase” and you’re guaranteed some solid engagement farming. It’s just an endless debate.

This is because Git provided us 2 different ways to perform more or less the same result, and this just puts the topic in “opinion land”.

With this premise, I’ll share my opinion.

You use both.

When working on a feature branch, and you’re ready to merge the branch into main (or another branch, but I’m simplifying), you rebase the feature branch upon main.

This means, all the changes that were committed to main are now being applied to the feature branch, then all the changes committed to the feature branch are applied after them.

Even if work continued on main and we have changes that we didn’t have before when the feature branch was created.

Even if:

1. you created the feature branch from main 3 days ago
2. committed 10 changes on the feature branch 2 days ago
3. yesterday you added to main some commits

…after you rebase the feature branch upon main, it’ll be like the commmits made to main yesterday were done before you even created the feature branch.

You resolve any conflicts during this rebase.

Then once you are ready, assuming no more changes were made to main (otherwise rebase again), you can merge the feature branch into main, doing what we call “fast-forward merge”.

Doing so will prevent the infamous merge commit, which is one of the main reasons why we do not just use git merge right away, but first we rebase the branch we want to merge.

Other reasons include not mixing commits from different branches in the history, and having a cleaner git log.

I want to highlight this, if there is something you should get from this tutorial, is that you never rebase main, because that would rewrite the history of the main branch and assuming other people use it as the base of their work, it’s not going to have an happy ending.

It’s possible, but I’d not do it.

I’d only rebase feature branches upon main.