git merge & git rebase

git merge and git rebase two are used to merge two branches, and in the process of use, these two concepts are easy to confuse.

Here, the usage of these two git tricks is described in detail, hoping to help some git-loving friends.

------------------------------------------------------------------------------------------------------

git merge is used to merge two branches.

git merge B

# merge the B branches into the current branch

The same git rebase is also used to merge the changes of a branch into the current branch.

------------------------------------------------------------------------------------------------------

First, they have the following principles:

Suppose you now create a branch called "MyWork" based on the remote branch "origin". $ git Checkout-b mywork origin assumes that the remote branch "origin" already has 2 commits, now we make some modifications in this branch and then generate two commits. $ VI file.txt$ git commit$ vi Other file.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. In this case, 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): But if you want the "mywork" branching history to look like it hasn't been merged, , you might be able to use git rebase:$ git checkout mywork$ git rebase origin These commands will cancel each commit in your "mywork" branch and temporarily save them as patches (  These patches are placed in the ". Git/rebase" directory, then the "mywork" branch is updated to the newest "origin" branch, and 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 conflictsIn 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 so 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 mergeNow we can look at the difference between the history of merging and using rebase: When we use git log to see Commit, the order of the commits is different. Suppose C3 commits to 9:00AM,C5 submitted in 10:00AM,C4 submitted to 11:00AM,C6 submitted in 12:00am, the order in which to merge the observed commits using 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 just C5 commits the clone, from the user's point of view using Git The Order of commits (from new to old) that rebase to merge is: C7, C6,c5,c4,c3,c2,c1 *********************************************************** ****************************************************

Git rebase, as its name implies, is redefining (re) the role of the starting point (base), which is to redefine the repository state of the branch. To figure this out, take a look at the two scenarios of repository State switching:

1. We know that on a branch, we can use git reset to switch the current branch to any previous version state of the branch, known as "backtracking". The "regret medicine" of this branch is realized. is the original intention of the version control system.
2. There is another situation when our project has multiple branches. We may "backtrack" in addition to local development, and will often add to our own local side changes to others that we have developed in parallel. This situation is common. As a project administrator, it is certain that patches for individual sub-projects will be constantly merged and that the latest versions will be pushed to the public repository, and as one of the developers who submit their own patches, they often need to update their work to the latest repository, that is to say, the work of other branches.

For instance! Suppose our project initially had only one master branch, and then two commits on the branch. This time the system has only one master branch, and his branch history is as follows:

Master0 (initialized version)
||
V
Master1 (the first post-commit version)
||
V
Master2 (second post-commit version)

At this point, we can switch the master branch (working directory, work cache, or repository) to the Master1 or MASTER0 version via Git reset, which is the first case mentioned earlier.
Let's say that we've traced the master branch back to the Master1 state through git reset. So this time the system still has only one master branch, the history of the branch is as follows:

Master0 (initialized version)
||
V
Master1 (the first post-commit version)

We then create another branch test here, starting with Master1. So for the Test branch, his first version of Test0 is the same version as Master1, when the branch history of the project is as follows:

Master0 (initialized version)
||
V
Master1 (the first commit version) ===TEST0 (Test branch, initialized from the master branch Master1 State)

At this point, we make two commits to the master branch and the test branch respectively, and the repository should look like this:

Master0 (initialized version)
||
V
Master1===test0==>test1===>test2
||
V
Master2===>master3

1. This time, with the first git reset, the current state of the Master Branch (MASTER3) can be traced back to the Master0, Master1, Master2 State of the master branch. The test branch's current state (TEST2) can also be traced back to the test0, test1 state of the Test branch, and the Master0, Master1 state of the parent branch master of the Test branch.
2. So. If I want all the changes from test0 to Test2 to be added to the master branch for the test branch, the master branch contains all the modifications to the Test branch. Git rebase will be used at this time.

First, we switch to the master branch and then run the following command to achieve our requirements:

1	Git rebase test

What does git do this time?

1. Checkout the code of the Test branch first, as the working directory
2. The Master branch is then created from the Test branch with all the changed patches, sequentially. If there's no problem with the patching process, Rebase's done.
3. If there is a problem with patching, you will be prompted to handle the conflict. Well, you can run Git rebase–continue and continue until you finish.
4. If you don't want to, you still have two options, one is to abandon the rebase process (run Git rebase–abort), and the other is to replace the current branch (git rebase–skip) directly with the Test branch.

git merge & git rebase