Rebasing instead of Merging

Rebasing instead of Merging

·

3 min read

When we develop with git, we usually make some changes in another branch and merge it back to the master branch later. But as you know, with git merge, a merge commit will be created automatically and this may not be what you want. Combining changes with git rebase could give us a cleaner history. Let's how it can be done.

First, do the following steps to prepare the basic test environment.

% git init
Initialized empty Git repository in ...

% touch 1.txt

% git add .

% git commit -m "1.txt"
[master (root-commit) 4d97bac] 1.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 1.txt

% git checkout -b feature
Switched to a new branch 'feature'

% touch 2.txt

% git add .

% git commit -m "2.txt"
[feature 5f716ce] 2.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 2.txt

% git checkout master
Switched to branch 'master'

% touch 3.txt

% git add .      

% git commit -m "3.txt"
[master 1e36911] 3.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 3.txt

As you can see, we create 2 branches: master and feature.

Let's see the history of master.

% git log --graph
* commit e431d6d9cd3292cbefab8a01b50f339c7d208fd4 (HEAD -> master)
| Author: yao
| Date:   Fri Oct 7 20:25:31 2022 +0900
| 
|     3.txt
| 
* commit 479d9d43dc07f7859cf85690f9633360d999e97e
  Author: yao
  Date:   Fri Oct 7 20:24:57 2022 +0900

      1.txt

Then the history of feature.

% git log --graph
* commit 79dd1de41bcc723da3a6889593d808073437f401 (HEAD -> feature)
| Author: yao
| Date:   Fri Oct 7 20:25:17 2022 +0900
| 
|     2.txt
| 
* commit 479d9d43dc07f7859cf85690f9633360d999e97e
  Author: yao
  Date:   Fri Oct 7 20:24:57 2022 +0900

Now if we do git merge on master branch, then master branch's history becomes below.

% git merge feature

% git log --graph
*   commit 4f30acd8c08e17dcc64e63fde78771ae1686aa6c (HEAD -> master)
|\  Merge: e431d6d 79dd1de
| | Author: yao
| | Date:   Fri Oct 7 20:27:24 2022 +0900
| | 
| |     Merge branch 'feature'
| | 
| * commit 79dd1de41bcc723da3a6889593d808073437f401 (feature)
| | Author: yao
| | Date:   Fri Oct 7 20:25:17 2022 +0900
| | 
| |     2.txt
| | 
* | commit e431d6d9cd3292cbefab8a01b50f339c7d208fd4
|/  Author: yao
|   Date:   Fri Oct 7 20:25:31 2022 +0900
|   
|       3.txt
| 
* commit 479d9d43dc07f7859cf85690f9633360d999e97e
  Author: yao
  Date:   Fri Oct 7 20:24:57 2022 +0900

      1.txt

As you can see, the commits from feature branch will be appended on the master branch and a new merge commit is created automatically.

If we do not use git merge, but to use rebase on branch master, then the history becomes below.

% git rebase feature
Successfully rebased and updated refs/heads/master.

% git log --graph
* commit dad366070b8c48bc5cdf6fef2dd4f3a2dd91a81c (HEAD -> master)
| Author: yao
| Date:   Fri Oct 7 20:25:31 2022 +0900
| 
|     3.txt
| 
* commit 79dd1de41bcc723da3a6889593d808073437f401 (feature)
| Author: yao
| Date:   Fri Oct 7 20:25:17 2022 +0900
| 
|     2.txt
| 
* commit 479d9d43dc07f7859cf85690f9633360d999e97e
  Author: yao
  Date:   Fri Oct 7 20:24:57 2022 +0900

      1.txt

As you can see, with git rebase, the changes from feature branch are inserted between common ancestor commit(1.txt) and changes on branch master(3.txt) and no new commits created. So just like the name rebase means, when using git rebase, we actually want to base my current changes(3.txt) on changes other people already done(2.txt). And finally we get a linear and cleaner git log history.