Git rebase)

Git rebase, as its name implies, is to redefine the version database status of a branch. To understand this, we need to first look at the two situations of version database status switching:

1. We know that on a branch, we can use git reset to switch the current branch to any previous version of the current branch, that is, "backtracking ". That is, the "regret" of this branch is realized ". That is, the original intention of the version control system.
2. There is another case when our project has multiple branches. In addition to local development, we may also trace back, and often add the branch modifications of others that we develop in parallel to our own local. This is common. As a project administrator, patches for each sub-item are constantly merged and pushed to the public version library. As a developer, after you submit your own patches, you often need to update your work to the latest version library, that is, to include the work of other branches.

For example! Assume that there is only one master branch in the initial stage of our project, and the branch has been submitted twice. At this time, the system only has one master branch. Its branch history is as follows:

Master0 (initialized Version)
|
V
Master1 (version after the first submission)
|
V
Master2 (version after the second submission)

At this time, we can switch the master Branch (working directory, working cache or version Library) to master1 or master0 through git reset, which is the first case mentioned above.
Let's assume that the master branch goes back to the master1 State through git reset. At this time, the system still has only one master branch. The branch history is as follows:

Master0 (initialized Version)
|
V
Master1 (version after the first submission)

Next, we create another branch test from master1. For the test branch, the first version of test0 is the same as that of master1. The branch history of the project is as follows:

Master0 (initialized Version)
|
V
Master1 (version after the first submission) === test0 (test branch, initialized from Master branch master1 status)

At this time, we submit the master Branch and the test branch two times respectively. At this time, the version library should look like this:

Master0 (initialized Version)
|
V
Master1 === test0 ==> test1 ==> Test2
|
V
Master2 ==> master3

1. In this case, the current status (master3) of the master branch can be traced back to the master0, master1, and master2. The current status of the test Branch (Test2) can also be traced back to the test0 and test1 statuses of the test branch, and the master0 and master1 statuses of the master of the parent branch of the test branch.
2. So. If I want to add all the changes from test0 to Test2 to the master branch, the master branch contains all the modifications of the test branch. Git rebase is required at this time.

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

1	GitRebaseTest

What does git do at this time?

1. FirstCodeAs the working directory.
2. Then, all the changed patches created from the master branch from the test branch are marked in sequence. If there is no problem with patching, rebase will fix it.
3. If a problem occurs during patching, you will be prompted to handle the conflict. After processing, you can run git rebase-continue to continue until it is completed.
4. If you don't want to deal with it, you still have two options: one is to discard the rebase process (run git rebase-Abort ), the other is to replace the current Branch (GIT rebase-Skip) with the test branch directly ).

In addition, rebase allows you to submit the modification before the modification. This function will be available later.