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
mergewhile 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.
Oldest comments (0)