# Git, rebase vs merge

> When should you use git rebase vs merge? My take: rebase your feature branch onto main for a clean history, then fast-forward merge, and never rebase main.

Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2024-04-16 | Topics: [Git](https://flaviocopes.com/tags/git/) | Canonical: https://flaviocopes.com/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](https://flaviocopes.com/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.