Git Step by step– (8) git merge and rebase

As mentioned in the previous article, "Git pull" is equivalent to "git fetch" plus "git merge", and then mentions the pull command to support rebase mode, this article describes the difference between merge and rebase.

Since we mainly want to see the difference between merge and rebase, here is a demonstration with the branch of the local repository.

Merge

In fact, in the introduction of the branch of the article has introduced some of the content of the branch merge, here are some additions and summaries.

Here we start with a local warehouse, the current branch of the warehouse is as follows:

In fact, there are three things that can happen when the merge command is summarized:

1. The merge command does not take effect

   When the target branch is the ancestor commit node of the current branch, that is, the current branch is already up to date, in which case the merge command has no effect.

   In the current warehouse, when we merge the Dev branch to master, we get "already up-to-date."

2. Fast-forward merge mode

   Fast-forward merge occurs when the current branch is the ancestor commit node of the target branch, see

   The object model is updated, where the merge operation simply updates the head reference of the dev branch to the latest commit object

3. Three-party merger

   Please refer to the "Git Step by step– (5) Git Branch (branch)" Branch merge content. If there is no conflict, Git will help us to complete the branch merge, if there is a conflict, we need to resolve the conflict manually.

Fast-forward merge mode

In the front we see the fast-forward merge pattern, which is simple, just the update of the head reference. However, after merging, we will not see the branch information from "Git log".

In Git, we can choose to disallow fast-forward when the merge is in. Now, let's undo the previous fast-forward merge with "git reset--hard head~1".

We then add "--no-ff" to the merge command to do the merging.

Cherry-pick

Here we will insert a very useful command, although it has nothing to do with the merge.

In practical applications, we may often encounter this situation and submit an update on branch A, but later we find that we also need to apply this update on branch B. Then Cherry-pick can help you solve the problem.

All we have to do is find the updated SHA1 hash of a on "Git reflog" and switch to "Git Cherry-pick" on the B branch.

When we manually merge the conflicts and then proceed to "Cherry-pick", Git gives a friendly interface, and if we do not need to update the submitted message, we can simply ": Wq" to save the exit. In this case, the "Cherry-pick" operation was successful.

Rebase

Before we introduce the merge, let's look at rebase. In the process of merge, it is better that we can see the historical information of the branch, but if the branches are many, the branch history may become very complicated. If we use rebase, then the commit history will remain linear.

rebase : First, the head reference of the current branch points to the common ancestor commit node of the target branch and the current branch, and then the commit on the current branch is applied to the target branch, and then the head reference is pointed to the current branch after the apply. is not a bit around, let's look at an example below.

Starting with Rebase's introduction, we'll create a new release-1.0 branch based on master and submit an update on that branch.

At this point, we execute "git rebase master" on the release-1.0 branch, and we get the following object graph.

According to the working principle of rebase Analysis:

1. Point the head reference of the current branch to "00abc3f"
2. Then apply the commit on the current branch to the target branch, here is the "ed53897" update apply to master; Note that if there is no conflict, a new update will be generated directly here
3. Finally update the current branch's head reference to perform the latest commit "8791E3B"

This is the rebase operation, and we can see that our commit history will remain linear through rebase operations. In this case, when we switch to the master branch and then the "Git merge release-1.0" branch merge, Master will be the fast-forward merge mode directly, and the commit history will be linear.

Of course, the rebase operation will also create a conflict, when a conflict occurs, we can skip the current patch (be careful, do not use casually, so as not to lose the update), you can manually resolve the conflict, and then continue to rebase operation

Rebase Interactive mode

In fact, Rebase has other very powerful features, such as rebase interaction mode, through which we can change the commit information, delete commits, merge commits and change the order of commits, and so on.

If we want to update a commit now, we can use the Rebase interactive mode to find the commit hash and enter the interactive mode.

Depending on the rebase operation prompt, we select Edit and save the exit.

At this point, Git will prompt us whether to make a change or to continue the operation. Here we go through "git commit--amend" into edit mode.

The commit is updated in edit mode and then saved to exit to continue the rebase operation.

About rebase Interactive mode of other commands, here do not introduce, interested students can Google a bit.

Summarize

This article mainly introduces the merge and Rebase. There is no difference between rebase and merge for the final result, and there is no case that rebase and merge will result in inconsistent final updates.

The main differences between rebase and merge are:

• Rebase is clearer because commit history is linear, but commit is not necessarily by date, but the commit of the current branch is always behind (refer to the rebase principle)
• After merge, commit history becomes more complex and partly reflects the information of each branch, and commits are sorted by date.

You can choose which method to use to pull remote updates based on your project needs.

Git Step by step– (8) git merge and rebase