The use of the git rebase command, compared to the merge command

git rebase command

1. Basic use

1. Create a new project on github

   

2. There is a master branch by default ( note: the branch created by Github by default is the main branch)

   

3. clone the project locally

Simulate daily development

A classmate's operation

1. execute git log

   

   It can be seen that the project has only one submission record at this time

2. Add files and perform commit and push operations

   

3. Refresh Github and find the records submitted by classmate A

   

4. Check out a new branch dev based on the local master branch with two commit records, and push the branch to the remote repository

   

5. Check the remote warehouse, there is one more dev branch

   

6. At this point, the local git branch diagram is similar to the following (C1, C2 represent the submitted version)

   

7. Suppose classmate A develops functions based on the dev branch, and has made three new code submissions locally. The git log is as follows

   

8. The git branch diagram at this time is as follows

   

Classmate B's operation

If another student B pushes a master branch submission to the remote warehouse before classmate A prepares to make the fourth local submission, that is, the actual submission of master has moved forward at this time:

A classmate's operation

1. Switch to the master branch and get the latest code submitted by master B

2. The branch diagram at this time is as follows

   

3. The dev branch developed by classmate A is cut based on the C2 commit point, and the master branch has been updated at this time. If classmate A has completed the development and needs to merge its functions into the master branch, he can have two choices:

   • git merge
   • git rebase

Method 1: git merge

Switch to the master branch and execute the git merge devcommand . The execution process of the command is as follows:

• Find the commit point of the nearest common ancestor of the dev branch and the master branch, i.e. C2

• Merge the latest commit of dev (C5) and the latest commit of master (C6) to generate a new commit (C7). If there is a conflict, you need to resolve the conflict

• Put all the commit points (from C2 onward) on the above two branches dev and master on the master branch in the order of the commit time (that is to say, all committed records will be retained)

• The branch diagram at this time is as follows:

  

Afterwards, classmate A continues to develop in the dev branch, and the master continues to move forward. If a merge occurs, repeat the above steps.

Disadvantages of this way:

Since merge will record all kinds of information of all branches, if there are many project branches and more commits, the following situation will occur, which is too complicated:

Method 2: git rebase

1. You need to pull the master code to the latest before rebase

2. In the dev branch, execute the git rebase mastercommand , and the effect after execution is as follows:

   

   It can be found that there is no more commit, and the commit hash value submitted several times after dev has changed, including C3, C4, and C5.

3. Switch to the master branch and execute git rebase devit. The effect after execution is as follows:

   

   It is found that the rebase method is used to merge branches, and the entire master branch does not have a new commit. The hash value of the commits on the original dev branch (C3, C4, C5) has changed after rebase, and the entire master branch has changed. The commit record is linearly recorded , as shown below:

   

   Note: The C6 of the original master is before the C3 of the dev.

Summarize

1. The git merge operation merges branches so that each commit of the two branches is sorted according to the commit time (not the push time), and the latest commit point of the two branches is merged into a new commit, and the final branch tree is presented. In the form of a non-entire linear line.

2. The git rebase operation actually breaks up all the commits that are currently executing the rebase branch based on the commit point of the original branch into patches (patches) one by one, and regenerates a new commit hash value based on the latest commit of the original branch. Commit at the point (so you need to pull master to the latest) , which keeps the entire branch tree perfectly linear.

3. Comparison chart of the two methods:

   

2. -i parameter merge commit

In daily development, code changes are frequent, and sometimes you want to merge the previous submissions into one submission (for example, multiple submissions of a function only keep the last submission), which can be done by using the git rebase -i command.

Format:

git rebase -i [startpoint] [endpoint]

Where -i means –interactive, that is, an interactive interface pops up for the user to edit and complete the merge operation. [startpoint] [endpoint] specifies an editing interval. If [endpoint] is not specified, the end point of the interval defaults to the current one. The commit point pointed to by branch HEAD ( note: this interval specifies an interval that opens before and closes later )

Example:

// 合并从当前head到15f745b(commit id)
git rebase -i 15f745b

// 合并最近的两次提交
git rebase -i HEAD~2

After executing this command it will jump to a vi editor:

Modify the front end of the commit that you want to compress in this editor to s, where s is the abbreviation of squash, which means to compress this commit into the last commit.

Enter :wqto save, the following interface will pop up:

Enter :wqto save, then enter git push -fto sync with github.

3. Supplementary Instructions

git rebase --continue: Continue the rebase operation. For example, if a conflict occurs during rebase, git add after the solution is completed, and then execute git rebase --continueto continue the rebase operation.

git rebase --abort: Terminate this rebase operation.