Rebasing a Branch in Git
Tags: git, rebase, branch
Published: 2019-08-25 10:52:27

---
title: Rebasing a Branch in Git
published: true
description: 
tags: Git, Rebase, Branch
---

> In this post you'll learn how to use Rebase to combine two branches.
 
## Integrating Branches In Git

If you have two diverging branches and want to integrate from one into another, you would typically accomplish that in two ways in Git.

- Merge
- Rebase

It is pretty clear what `merge` does from its name. But what in the world  `rebase` means and why do you need it? Before you jump into `rebase`, let's take a look at how `merge` works first.

## Merge
`merge` command performs a `three-way merge` between the two latest branch commits and base commit which is the most recent common ancestor of the two branches.

For example below, there are two branches: a "feature" branch with a few commits and "master" branch.

![git-branches.png](https://images.velog.io/post-images/godori/bfb81f20-b147-11e9-a131-ff9a59280693/git-branches.png)

Assume that the last commit of each feature and master is `f2` and `m2`, and there is `b` which is the common ancestor of the two branches. Therefore you can create new commit based on those three commits.

Okay, so what actually is the process of `three-way merge` then? What would happen if you were doing a `two-way merge`?

### 3-way merge
Let's see why the 3-way merge is more efficient.

Note that each a, b, c, d is part that is modified from the base commit which is the common ancestor.
 
![image.png](https://images.velog.io/post-images/godori/cc6dd5f0-b149-11e9-9a09-5b90e5f36c66/image.png)

The following table shows the modified part in `My` branch and the `Other` branch.

![image.png](https://images.velog.io/post-images/godori/ba58aa60-b14a-11e9-a131-ff9a59280693/image.png)

First, `a` hasn't changed in my branch but other modified it. Secondly, `b` is unchanged on both sides. `c` has changed differently. Lastly `d` 's only changed on my branch.
 
Let's say that we will merge comparing only two branches without common ancestor.

![image.png](https://images.velog.io/post-images/godori/a2ba1b40-b14b-11e9-a131-ff9a59280693/image.png)

But it's hard to know if conflict happens except the part b which is observed same on both sides.

For this reason, we use the 3-way merge including the base commit during comparison to decide status of merge commit more clearly.

![image.png](https://images.velog.io/post-images/godori/2e3c85e0-b14c-11e9-9a09-5b90e5f36c66/image.png)

In short, when merging two commit into one, we use the last commits of each branches and the latest common ancestor of the them.

## Rebase
Rebasing is the second way to combine multiple branches into one, which changes base the common ancestor to the different commit point. Let's have a look at the picture of branches again.
![git-branches.png](https://images.velog.io/post-images/godori/a27c8b20-b14d-11e9-a131-ff9a59280693/git-branches.png)

What we want to see using rebase is like this!

![image.png](https://images.velog.io/post-images/godori/bf044d70-b2d1-11e9-a332-d525eafa8638/image.png)


In other words, you did re-basing the feature's base commit to `m2` not `b`.

**Here's the basic strategy of `rebase`**

First off, git take patch of the changes from the commits and save it somewhere. Then it applies those to the master branch to create the new commits.


Rebasing feature to master branch goes through a series of steps.

```
1. Checkout to the feature branch
2. Rebase into the master branch
3. Fast-Forward Merge: feature branch into the master branch
```
![image.png](https://images.velog.io/post-images/godori/6e494040-b15d-11e9-8bdc-2f7c5d6ac42c/image.png)

> Why we need a `merge` while rebasing? Take a look at [fast-forward merge](https://www.youtube.com/watch?v=_4JdLEhxlBQ)

Here's a step-by-step guide to rebasing.

### Step 1
```
git checkout feature
```
After the checkout, HEAD points to the feature.

![image.png](https://images.velog.io/post-images/godori/174abe40-b15d-11e9-a131-ff9a59280693/image.png)

### Step 2
```
$ git rebase master
```
Git stores the differences(`▵1`, `▵2`) from the base commit of master and feature to the commit of current branches.

![image.png](https://images.velog.io/post-images/godori/8fa81e80-b15f-11e9-a308-131479da2b82/image.png)

### Step 3
Make HEAD point to the master

![image.png](https://images.velog.io/post-images/godori/8b3a3d10-b15f-11e9-a308-131479da2b82/image.png)

### Step 4
```
Applying f1
```
After that, commit `f1` is created by applying the `▵1` into the `m2`.

![image.png](https://images.velog.io/post-images/godori/ade9a210-b15f-11e9-9a9a-0f3d00cfbaf3/image.png)

### Step 5
```
Applying f2
```
Create a new commit `f2'` applying `▵2` diff on `f1'`

![image.png](https://images.velog.io/post-images/godori/f4617d30-b15f-11e9-9a9a-0f3d00cfbaf3/image.png)

### Step 6
Now make `feature` branch points `f2'`.

![image.png](https://images.velog.io/post-images/godori/2429d990-b160-11e9-9a9a-0f3d00cfbaf3/image.png)

### Step 7
```
git merge feature
```
A rebase does not move the position of the master. You are able to complete all the process with a `fast-forward merge` after rebasing.

![image.png](https://images.velog.io/post-images/godori/b9224b40-b160-11e9-9a9a-0f3d00cfbaf3/image.png)


## Merge vs Rebase
Which is better for combining two branches? It depends on the situation of your team and the project.

If you want to remain all the commits including changing history, you can use the `merge`. On the other hands if you want to keep a linear history without any merge commit, you should choose the `rebase`.


## References
- [Pro Git - Rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)