Why do you want to be gay

Git official documentation states:

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

We merge code from a branch to make changes. When we commit, if someone else makes changes, we merge our changes with their changes. What does rebase mean in Chinese? Must first understand the base, the base is the basic meaning, when we get the code from the code branch, we have a foundation, which is the base, and then modify our is carried out based on this, but when we need to commit changes, met with the other people’s code, rebase this operation is at this time, Instead of merging other people’s code, we simply change our original base and rework our changes on top of the new code that others have modified. The basis has changed, so it’s called a radical.

So what are the benefits of being gay? One advantage is can make our time line become very clean, before, when using the merge in the time line from which a complete record of our code, pull out on the basis of made what changes, and then merged to go back to branch, at which time and use rebase, time online is no longer reflect the pull point in time, Because each commit is based on the latest code, the timeline becomes a straight line.

Here are two real examples to give you a more intuitive view:

Here is the timeline before the automatic base change was adopted, and you can see the various messes:

Here’s a neat timeline with autobase, so you can see what happened after one change, rather than multiple changes being entangled:

Automatic rebase

Although there are many tutorials on the Internet about the change base, but general beginners will always feel at a loss, dare not easily start, afraid of ten thousand a time line broke, out of control. Moreover, all the commands related to rebase are different from the pull/add/commit/push commands we have been used to for many years. Many graphical tools such as vscode do not directly support rebase commands, which require manual input, tedious and error prone. So we’re not going to talk too much about how to use the rebase command today. Instead, we’re going to use two commands to set it up so that from now on you can automatically rebase every commit without changing any of your previous habits. These two commands are:

git config --global pull.rebase true
git config --global rebase.autoStash true
Copy the code

These two commands only need to be set once on any computer, and once set, global effect, all projects after each pull/push will automatically base, no longer need to worry about forgetting to base before committing.

The principle of

If you do not want to understand the principle, then execute the above two commands can be happy to change the base, no problem at all. If you want to see how this works, you can read on. Let’s explain how these two commands work in detail:

First, let’s be clear: when is the time to change the basis? It is generally understood that when you push, it is not, but when you pull, you will start to change the base, because when you pull, the server may have new code, so to change the base is also at this time, once you find a new base, it will change immediately. So, normally, pulling new code is nothing more than a command: git pull, but now to change git pull, you need to use Git pull –rebase. But it’s a hassle to do this every time, and there’s no way you can add this parameter automatically in vscode, so for convenience, let’s set the first command so that it automatically rebases every time we pull it.

But autobase often presents an additional problem, which is that every time you have a file in the process of editing, it says it can’t base because your workspace isn’t clean. Why is this not a problem with base invariance, but once automatic base change is selected, the workspace must be kept clean? Because rebasing works by reverting commits from your local code base to your workspace that haven’t been pushed yet, pulling new code from the server, and attaching changes to the workspace based on the new code, it has to require that your workspace be clean. Git has two suggestions for this: either commit all changes locally or stash them. First of all, it is not a good idea to commit, because it is likely that we are halfway through our work and not ready to commit. If we commit every pull, there will be too many useless nodes on the branch tree. That only leaves one last option, which is to stash everything before each pull and pop it out after, but isn’t that more trouble? So let’s set it up with the second command. Every time we rebase, the contents of our workspace will be automatically stash into it, and then automatically restore out after rebase is completed.

Git rebase –continue: git rebase –continue: git rebase –continue: Git rebase –continue: Git rebase –continue: Git rebase –continue: Git rebase –continue