Git official documentsIt is mentioned in:
There are two main ways to integrate modifications from different branches in Git:
mergeas well as
merge, this concept is easy to understand. We pull the code from the branch for modification. When submitting, if we encounter other people’s modifications, we will merge our modifications with their modifications. that
rebaseWhat does the Chinese translation mean? First understand this
baseThat means foundation. When we get the code from the code branch, we have a foundation, that is
baseHowever, when we need to submit changes, we encounter other people’s code. This is when we change the base. Instead of merging other people’s code, we directly change our original base to be based on the new code modified by others, We should redo our revision on this new basis. The foundation has changed, so it is called
So what are the benefits of changing the base? One of the advantages is that it can make our timeline very clean. In the past, when merging was adopted, the timeline completely recorded the basis on which our code was pulled and what modifications were made, and then merged back to the branch at which time point. After changing the base, the timeline no longer reflects the pulled time point, Because each submission is based on the latest code, the timeline becomes a straight line.
Here are two real examples to show you more intuitively:
This is the timeline before automatic base change. You can see all kinds of confusion:
This is the timeline after automatic base change. It is very neat. You can clearly see what changes have occurred after which modification, rather than entangled with multiple modifications:
Automatic base change
Although there are many online tutorials on changing the base, ordinary beginners always feel at a loss and dare not start easily, for fear that if the timeline is damaged, it will get out of control. And all the commands about changing the base are the same as we have been used to for many years
pull/add/commit/pushDifferent, many graphical tools, such as vscode, do not support it directly
rebaseSuch commands require manual input, which is cumbersome and error prone. So we won’t talk much today
rebaseCommand how to use, and directly set it with two commands, so that you can automatically change the base every time you submit, without changing any previous operation habits. These two commands are:
git config --global pull.rebase true git config --global rebase.autoStash true
These two commands only need to be set once on any computer, and once set, the global effect will take effect, and all items will take effect every time in the future
pull/pushWill automatically change the base. You don’t have to worry about forgetting to change the base before submitting.
If you don’t want to understand the principle, you can happily change the base after executing the above two commands. There is no problem at all. If you want to understand some principles, you can go on. Let’s explain the principles of these two commands in detail:
First of all, we should make it clear: what is the time to change the base? It is generally understood that when pushing, in fact, it is not. It starts to change the base when pulling, because when you pull, there may be new code on the server, so it is also at this time to change the base. Once a new base is found, it will be changed immediately. Therefore, generally, pulling new code is nothing more than a command:
git pullBut now if we want to change the base pull, we need to use it
git pull --rebase。 However, it will be troublesome to execute the command every time, and you can’t add this parameter automatically in vscode, so for convenience, we’ll set the first command so that it will change the base automatically every time you pull it.
However, automatic base change often brings an additional problem. That is, every time you have a file you are editing, it says it can’t change the base because your workspace is not clean. Why is there no such problem when changing the base, and once automatic base change is selected, the workspace must be kept clean? Because the operation principle of base change is that it needs to submit and release the part of your local code base that has not been pushed back to the workspace, then pull the new code from the server, and then attach the modifications in the workspace based on the new code. Because of this process, it must require that your service area is clean. To this end, GIT made two suggestions: either you change everything first
commitGo local, or you’ll take them all
stashSave it. First,
commitIt’s definitely not a good idea, because it’s likely that we’re halfway through our work at this time
commit, if every time
commitIf you do this, there will be many useless nodes on the branch tree. There’s only one last choice left, every time
pullWhen you’re done
popCome out, but isn’t it more troublesome? So here we use the second command to set it every time
rebaseThe content in our workspace is automatically updated when
rebaseAutomatically recover after completion.
The other thing to pay attention to is when there is conflict,If there are conflicts, perform the following steps after merging the conflicts
git rebase --continueJust fine, others are no different from the original usage.