关于git:两条命令让你的git自动变基

5次阅读

共计 1840 个字符，预计需要花费 5 分钟才能阅读完成。

Git 官网文档中提到：

在 Git 中整合来自不同分支的批改次要有两种办法：merge 以及 rebase。

merge也就是 合并 ，这个概念很容易了解，咱们从分支上拉取代码进行批改，再提交的时候，如果遇到了他人的批改，则把咱们的批改和他们的批改合并一下。那么rebase 中文译为变基是什么意思呢？首先要了解这个 base，base 也就是根底的意思，当咱们从代码分支上获取代码的时候，咱们就有了一个根底，也就是 base，尔后的批改咱们都是在这个根底之上进行的，然而当咱们须要提交批改的时候，遇到了他人的代码，变基这个操作就是在这个时候，咱们不去合并他人的代码，而是间接把咱们原先的根底变掉，变成以他人批改过后的新代码为根底，把咱们的批改在这个新的根底之上从新进行。根底变掉了，所以叫作 变基。

那么，变基有什么益处呢？益处之一是能够使咱们的工夫线变得十分洁净，以前采纳合并的时候，工夫线里残缺记录了咱们的代码是从哪个根底上拉取出来的，做了哪些批改，而后又在哪个工夫点合并回分支去，而采纳变基之后，工夫线上不再反映拉取的工夫点，因为每次提交都是以最新代码为根底的，所以工夫线就变成了一根直线。

上面拿两个实在例子给大家更直观地看一下：

这是采纳主动变基之前的工夫线，能够看到，各种凌乱：

这是采纳主动变基之后的工夫线，十分参差，能够很分明地看到哪一次批改之后又产生了什么批改，而不是屡次批改纠缠在一起：

尽管网上对于变基的教程很多，然而个别初学者总会感到茫然，不敢轻易下手，怕万一把工夫线弄坏了，一发不可收拾。而且所有对于变基的命令都和咱们曾经多年习惯了的 pull/add/commit/push 不一样，很多图形化的工具例如 vscode 也不间接反对 rebase 这样的命令，都须要手工输出，繁琐而且容易出错。所以咱们明天不讲太多的 rebase 命令怎么用，而间接用两条命令设置一下，从此以后让你每次提交都能够主动变基，而不用扭转之前的任何操作习惯。这两条命令就是：

git config --global pull.rebase true
git config --global rebase.autoStash true

这两条命令在任意一台电脑上都只须要设置一次，而且一次设置，全局失效，所有的我的项目当前每次 pull/push 都会主动变基，再也不必放心在提交之前遗记变基了。

如果不想理解原理的话，则执行完下面两条命令就能够去开心地变基了，齐全没有问题。如果想理解一些原理，能够接着往下看。上面咱们来具体解释一下这两条命令的原理：

首先，咱们要搞清楚一点：什么机会是变基的机会？个别了解是推送的时候，其实不是，而是从拉取的时候就要开始变基了，因为你拉取的时候，服务器上可能曾经有新代码了，所以要变基也是在这个时候，一旦发现有新根底了，则立马变掉。所以，通常状况下，咱们拉取新代码无非就是一个命令：git pull，但当初咱们要变基拉取，就须要用git pull --rebase。然而每次这样执行命令就会很麻烦，而且你在 vscode 里也没有方法主动加这个参数，所以为了不便起见，咱们就设置一下第一条命令，这样每次拉取它都会主动变基。

然而主动变基往往会带来一个额定的问题，那就是每次当你手头有正在编辑的文件的时候，它就说它无奈变基，因为你的工作区不洁净。为什么不变基的时候没有这个问题，而一旦抉择了主动变基，工作区就必须放弃洁净呢？因为变基的操作原理是它须要先把你本地代码库里还没有推送的那局部提交反向开释到工作区，而后从服务器拉取新代码，再以新代码为根底把工作区里的批改附加下来，因为有这个过程，所以它必须要求你的服务区是洁净的。为此 git 提了两个倡议：要么你把所有批改先全副都 commit 到本地，要么你把它们都 stash 保存起来。首先说，commit必定不是一个好主见，因为很有可能这时候咱们的工作做到一半，还不适宜 commit，如果每次pull 都commit一下的话，那么分支树上会多出很多无用的节点。那只剩下最初一个抉择，就是每次 pull 之前都 stash 一下，pull完了之后再把 stash 的内容 pop 进去，但这样岂不是更麻烦？所以这里咱们用第二条命令设置一下，每次 rebase 的时候都主动把咱们工作区里的内容主动 stash 进去，rebase实现之后再主动复原进去。