Skip to content

Git, rebase vs merge

New Course Coming Soon:

Get Really Good at Git

This post is part of my pre-launch series for my upcoming course Get Really Good at Git launching on May 21. If this post helps you, the course will be a great fit for you, to help you get a much better understanding of Git, reduce your frustrations with it, and figure out the good parts of this incredibly useful tool

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.

Are you intimidated by Git? Can’t figure out merge vs rebase? Are you afraid of screwing up something any time you have to do something in Git? Do you rely on ChatGPT or random people’s answer on StackOverflow to fix your problems? Your coworkers are tired of explaining Git to you all the time? Git is something we all need to use, but few of us really master it. I created this course to improve your Git (and GitHub) knowledge at a radical level. A course that helps you feel less frustrated with Git. Launching Summer 2024. Join the waiting list!

Here is how can I help you: