Compare git pull and git pull--rebase

1. Use the following relationship to differentiate between the two operations:
Git pull = git fetch + git merge
git pull--rebase = git fetch + git rebase2

First, the basic

Git rebase is used to merge changes from one branch into the current branch.

Suppose you now create a branch called "MyWork" based on the remote branch "origin".

$ git Checkout-b mywork origin

Suppose that the remote branch "origin" already has 2 commits,

Now let's make some changes in this branch and then generate two commits (commit).

$ VI file.txt

$ git commit

$ VI Otherfile.txt

$ git commit

...

But at the same time, some people have made some changes to the "origin" branch and have made submissions. This means that the two branches of "origin" and "mywork" each "Go forward" and "fork" between them.

Here, you can use the "pull" command to drop the changes on the "origin" branch and merge with your changes; The result looks like a new "merged commit" (merge Commit):

However, if you want the "mywork" branching history to look like it has not been merged, you might be able to use Git rebase:

$ git checkout mywork

$ GIT rebase origin

These commands will cancel each commit (commit) in your "mywork" branch and temporarily save them as patches (patches) to the ". Git/rebase" directory, and then update the "mywork" branch to the newest "origin" branch. Finally, the saved patches are applied to the "MyWork" branch.

When the ' mywork ' branch is updated, it points to these newly created commits, and those old commits are discarded. If you run the Garbage collection command (pruning garbage collection), these discarded commits are deleted. (See git GC)

Ii. Settlement of conflicts

In the process of rebase, there may be conflicts (conflict). In this case, Git will stop rebase and will let you resolve the conflict, after resolving the conflict, use the "git-add" command to update the index of these content, then you do not need to execute git-commit, as long as the execution:

$ git rebase--continue

This way git will continue to apply the remaining patches.

At any time, you can use the--abort parameter to terminate the action of Rebase, and the "MyWork" branch will return to the state before the start of rebase.

$ git rebase--abort

Iii. the difference between git rebase and git merge

Now we can look at the difference between the history created by merging and using rebase:

When we use git log to see Commit, the order of the commits is different.

Suppose C3 submitted to 9:00AM,C5 submitted at 10:00AM,C4 submitted to 11:00am,c6 submitted in 12:00am,

The order in which to merge the commit that you see with git merge (from new to old) is: C7, C6,C4,C5,C3,C2,C1

The order in which to merge the observed commits using Git rebase (from new to old) is: C7, C6 ', C5 ', C4,C3,C2,C1

Because C6 ' commits just C6 commits the clone, C5 ' commits only C5 commits the clone,

From the user's point of view, the sequence of commits (from new to old) that you see Using git rebase to merge is: C7, C6,C5,C4,C3,C2,C1

Also, when we use the git pull command, we can use the--rebase parameter, git pull--rebase, which means to cancel each commit (commit) in your local current branch and temporarily save them as patches (patches) that are placed in The ". Git/rebase" directory), then update the local current branch to the newest "origin" branch, and finally apply the saved patches to the local current branch. For more information on Git pull, please refer to "Git Pull introduction"

Compare git pull and git pull--rebase