Two commands make your git base automatically


Why base

Git official documentsIt is mentioned in:

There are two main ways to integrate modifications from different branches in Git:mergeas well asrebase

mergethat ismerge, 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. thatrebaseWhat does the Chinese translation mean? First understand thisbasebaseThat means foundation. When we get the code from the code branch, we have a foundation, that isbaseHowever, 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 calledVariable base

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:

Two commands make your git base automatically

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:

Two commands make your git base automatically

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 yearspull/add/commit/pushDifferent, many graphical tools, such as vscode, do not support it directlyrebaseSuch commands require manual input, which is cumbersome and error prone. So we won’t talk much todayrebaseCommand 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 futurepull/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 itgit 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 firstcommitGo local, or you’ll take them allstashSave it. First,commitIt’s definitely not a good idea, because it’s likely that we’re halfway through our work at this timecommit, if every timepullallcommitIf you do this, there will be many useless nodes on the branch tree. There’s only one last choice left, every timepullBeforestashonce,pullWhen you’re donestashContent ofpopCome out, but isn’t it more troublesome? So here we use the second command to set it every timerebaseThe content in our workspace is automatically updated whenstashGo in,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 conflictsgit rebase --continueJust fine, others are no different from the original usage.