Git Merge vs Git Rebase

**Git merge** and **rebase** serve the same purpose – they combine multiple branches into one. Although the final goal is the same, those two methods achieve it in different ways. *Which method to use?*

## What Does Merge or Rebase Mean?
Here you have a sample repository that has two **[diverging branches](https://kolosek.com/git-branches/)**: the master and the feature. You want to blend them together. Let's take a look how these methods can solve the problem. 

![git-flow](https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/fc73a41ce658a6a566e2a54d60534ade/git-flow.png)

### Merging
When you run `git merge`, your HEAD branch will generate a **new commit**, preserving the ancestry of each commit history.

![git-merge-2](https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/673b91456bdc6fd454c5ad203f825568/git-merge-2.png)

>[Fast forward merge](https://kolosek.com/git-merge/#fastforwardmerge) is a type of merge that doesn't create a commit, instead, it updates the branch pointer to the last commit.


### Rebasing
The **rebase** re-writes the changes of one branch onto another *without* creating a new commit. 

For every **commit** that you have on the [feature branch](https://kolosek.com/git-branches/) and not in the master, a new commit will be created on top of the master. It will appear as if those commits were written on top of master branch all along.

![git-rebase](https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/5ade4f7276bc6ad18dad4b6078950ac9/git-rebase.png)

## Merging Pros and Cons

### Pros:
- Simple to use and understand.
- Maintains the original context of the source branch.
- The commits on the source branch are separated from other branch commits. This can be useful if you want to take the feature and [merge](https://kolosek.com/git-merge/) it into another branch later.
- Preserves your commit history and keeps the history graph semantically correct.

### Cons:
- **History** can become intensely polluted by lots of merge commits because multiple people are working on the same branch in parallel. Visual charts of your repository are can become a mess and don't add too much information. *It can look like a London Tube Map Commit!*

![london-tube-map-commit](https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/c8b97f4dbb5f7d49fc3eb3624eafff79/london-tube-map-commit.png)

- [Debugging using git bisect](https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase) can become much harder due to the merge commits.

## Rebasing Pros and Cons

### Pros:
- Code history is simplified, linear and readable.
- Manipulating a single commit history is easier than a history of many separate feature branches with its additional commits. 
- Clean, clear **commit messages** make it better to track a bug or when a feature was introduced. *Avoid polluting history with 20+ single-line commits!*

### Cons:
- Lowering the feature down to a handful of commits can hide context.
- Rebasing doesn't work with **pull requests**, because you can't see what minor changes someone made. Rewriting of history is bad for teamwork!
> You need to be more careful with rebasing than when merging.

- It requires more work when dealing with **[conflicts](https://kolosek.com/git-merge/#howtodealwithmergeconflicts)**. Using rebase to keep your feature branch updated requires that you resolve similar conflicts again and again. While with merging, once you solve the conflicts, you're set. *You have to resolve the conflict in the order they were created to continue the rebase.*

## Which Method to Choose?
When your team uses a feature based workflow or is not familiar with rebase, then `git merge` is the right choice for you: 
- It allows you to preserve the commit history for any given feature while not worrying about overriding commits and changing history. It helps you avoid unnecessary [git reverts or resets](https://kolosek.com/git-reset-revert-and-checkout/)!
- Different features remain isolated and don't interfere with existing commit histories.
- Can help you re-integrate a completed feature branch.

On the other hand, if you value more a clean, linear history then `git rebase` may be most appropriate. You will avoid unnecessary commits and keep changes more centralized and linear!

**If you rebase incorrectly and unintendedly rewrite the history it can lead to serious issues, so make sure you know what you are doing!**

---

*Rebase or merge, what is your preference? Kolosek team leans more towards merge for our feature-based workflow.*

This article is originally published on [Kolosek Blog](https://kolosek.com/git-merge-vs-rebase/?utm_source=qi).