Two commands to make your git automatically rebase

Why rebase

Git official document mentioned:

There are two main ways to integrate changes from different branches in Git: merge and rebase .

merge also the merge. This concept is easy to understand. We pull the code from the branch to modify it, and when we submit it again, if we encounter someone else's modification, we will merge our modification with their modification. So what does rebase mean when translated into Chinese? First of all, we must understand this base , base is also the meaning of the foundation, when we get the code from the code branch, we have a foundation, that is, base , and subsequent modifications are made on this basis, but When we need to submit changes, we encounter someone else’s code. The operation of rebasing is at this time. Instead of merging other people’s code, we directly change our original foundation and become a new one modified by others. Based on the code, we reworked our modifications on this new basis. The base has changed, so it is called rebase.

So, what are the benefits of rebasing? One of the benefits is that it can make our timeline very clean. When we used merge before, the timeline fully recorded the basis from which our code was pulled, what modifications were made, and at what time Click to merge back into the branch, and after rebasing, the timeline no longer reflects the time point of the pull, because each commit is based on the latest code, so the timeline becomes a straight line.

Here are two real examples for everyone to have a more intuitive look:

This is the timeline before the automatic rebasing. You can see all kinds of confusion:

This is the timeline after the automatic rebase is adopted. It is very tidy, and you can clearly see what changes have occurred after which modification, instead of being entangled with multiple modifications:

Automatic rebase

Although there are many tutorials on rebasing on the Internet, the average beginner will always feel at a loss and dare not start easily. And all commands are based on change, and we have many years accustomed pull/add/commit/push not the same, a lot of graphical tools such as vscode does not directly support rebase such an order, we need to be entered manually, tedious and error-prone. So we will not talk too much rebase command today, but directly use two commands to set it up. From now on, you can automatically rebase every time you submit without changing any previous operating 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, it will take effect globally. All items pull/push future, so there is no need to worry about forgetting to rebase before submitting.

principle

If you don't want to understand the principle, you can happily rebase after executing the above two commands, there is no problem at all. If you want to understand some principles, you can continue to look down. Let us explain in detail the principles of these two commands:

First of all, we have to figure out one thing: when is the time to rebase? The general understanding is that when you push, it is not actually, but you will start to rebase when you pull, because when you pull, there may already be new code on the server, so it is also at this time to rebase. If a new foundation is found, it will be changed immediately. Therefore, under normal circumstances, we pull the new code is nothing more than a command: git pull , but now we want to rebase, we need to use git pull --rebase . But it will be very troublesome to execute the command every time, and you can't automatically add this parameter in vscode, so for convenience, we will set the first command so that it will automatically rebase every time it is pulled.

But automatic rebasing often brings an additional problem, that is, every time you have a file you are editing, it says that it cannot be rebased because your workspace is not clean. Why is there no such problem when the base is not changed, and once the automatic rebase is selected, the work area must be kept clean? Because the operating principle of rebasing is that it needs to first release the submitted part of your local code base that has not been pushed to the workspace, then pull the new code from the server, and then modify the workspace based on the new code. Attach it, because of this process, it must require your service area to be clean. For this reason, git made two suggestions: Either you put all the changes to commit locally, or you save them all stash . First of all, commit definitely not a good idea, because it is very likely that our work is half done at this time, and it is not suitable for commit . If each time pull is commit , then there will be a lot of useless nodes on the branch tree. It would only last remaining option is to each pull both before stash look, pull after the expiry then stash content pop out, but that it is more trouble? So here we use the second command to set it, every time rebase , the content in our work area will be automatically stash in 0614854ab7c2a8, and then automatically restored after rebase

The rest should be noted that there is a conflict of time, if there is a conflict, the conflict after the completion of the merger, the implementation of what git rebase --continue like , and other original usage does not make any difference.