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.
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.
The following table shows the modified part in My
branch and the Other
branch.
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.
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.
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.
What we want to see using rebase is like this!
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
Why we need a
merge
while rebasing? Take a look at fast-forward merge
Here's a step-by-step guide to rebasing.
Step 1
git checkout feature
After the checkout, HEAD points to the feature.
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.
Step 3
Make HEAD point to the master
Step 4
Applying f1
After that, commit f1
is created by applying the ▵1
into the m2
.
Step 5
Applying f2
Create a new commit f2'
applying ▵2
diff on f1'
Step 6
Now make feature
branch points f2'
.
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.
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
.
Top comments (0)