前言
笔者最近在主导一个我的项目的架构迁徙工作，因为迁徙我的项目的历史包袱较重，人员单干较多，在迁徙过程中免不了进行多分支、屡次commit的状况，工夫一长，git的提交记录便凌乱不堪，轻易截一个图形化的git提交历史给大家感受一下。

各种分支疯狂打架宛如后宫争宠的妃子们，之所以会呈现这种状况，次要还是因为滥用git merge命令并且不思考后续的了解老本导致的。现在在大厂工作的程序员们，频繁承受变更的需要，一旦一开始考虑不周到，就肯定会呈现了大量无意义的commit log，加上“麻利”理念的推广，产品的疾速迭代上线变成了外围指标，这些无意义的commit log便被“下次再解决”，长此以往就凌乱不堪了。
而咱们在看一些开源仓库时，会发现他们的commit记录非常整洁，其实这并不是社区的程序员能力更强，而是因为他们没有KPI大棒的鞭策，在提交代码前会花工夫整顿本人的commit log。而这就是本文的配角了——“Git Rebase”。
git rebase和git merge
git rebase，中文翻译为“变基”，通常用于分支合并。既然提到了分支合并，那就肯定离不开git merge这个命令。
置信每个老手程序员刚进入职场的时候，都会听到“xxx你把这个分支merge一下”这样的话。那么问题来了，如果你有6个程序员一起工作， 你就会有6个程序员的分支， 如果你应用merge, 你的代码历史树就会有六个branch跟这个主的branch交错在一起。

上图是 git merge 操作的流程示意图，Merge命令会保留所有commit的历史工夫。每个人对代码的提交是各式各样的。只管这些工夫对于程序自身并没有任何意义。然而merge的命令初衷就是为了保留这些工夫不被批改。于是也就造成了以merge工夫为基准的网状历史构造。每个分支上都会持续保留各自的代码记录，主分支上只保留merge的历史记录。子分支随时都有可能被删除。子分子删除当前，你可能看到的记录也就是，merge某branch到某branch上了。这个历史记录形容基本上是没有意义的。
而 git rebase 中文翻译为“变基”，变得这个基指的是基准。如何了解这个基准呢？咱们看一下下图。

咱们能够看到通过变基后的feature分支的基准分支产生了变动，变成了最新的master。这就是所谓的“变基”。
通过下面的两张图能够很显著的发现，这两种合并分支的形式最大的区别在于，merge后的分支，会保留两个分支的操作记录，这在git commit log 树中会以穿插的模式保留。而rebase后的分支会基于最新的master分支，从而不会造成分叉，从头至尾都是一条洁净的直线。

对于 git rebase 和 git merge 的具体用法不在本文的介绍范畴内，详情能够参考互联网上的其余材料。

在变基过程中，咱们通常须要进行commit的批改，而这也为咱们整顿git记录提供了一个可选计划。
放弃最近的几条记录整洁
假如咱们有一个仓库，我在这个仓库里执行了4次提交，通过 git reflog 命令查看提交记录如下。

如果咱们想将Commit-3、Commit-2和Commit-1的提交合并成一次提交（假如某次提交至改了一些pom文件），咱们能够间接执行上面的命令
git rebase -i HEAD~3
复制代码
-i 指的是 --interactive ，HEAD~3 指的是最近三次commit。
当然咱们也能够间接指定最新的一个想保留的 Commit的ID，在下面的例子中就是Commit-0的ID，因而咱们也能够写成
git rebase -i d2b9b78
复制代码
执行该命令后，咱们会进入到这么如下一个界面：

这个界面是一个Vim界面，咱们能够在这个界面中查看、编辑变更记录。无关Vim的操作，能够看我之前写的文章和录制的视频《和Vim的初次见面》
在看前三行之前，咱们先来看一下第5行的命令加深一下咱们对git rebase的意识。

翻译过去就是，将d2b9b78..0e65e22这几个分支变基到d2b9b78这个分支，也就是将Commit-3/2/1/0这几次变更合并到Commit-0上。
回到后面三行，这三行示意的是咱们须要操作的三个 Commit，每行最后面的是对该 Commit 操作的 Command。而每个命令指的是什么，命令行里都曾经具体的通知咱们了。

pick：应用该commit
squash：应用该 Commit，但会被合并到前一个 Commit 当中
fixup：就像 squash 那样，但会摈弃这个 Commit 的 Commit message

因而咱们能够间接改成上面这样

这里应用fixup，而不是squash的次要起因是squash会让你再输出一遍commit的log，图省事的话，能够无脑抉择fixup模式。

而后执行:wq退出vim编辑器，咱们能够看到控制台曾经输入Successful了。

这个时候咱们再来看下log 记录，执行git log --oneline

于是最近三次的提交记录就被合并成一条提交记录了。
放弃两头某些记录整洁
那如果不是最初的几个commit合并，而是两头间断的几个Commit记录，能够用上述办法整顿合并吗？答案是能够的，只不过须要留神一下。
咱们从新创立一个新的仓库

如果这次咱们想将"third commit"和"second commit"合并为一个提交，其实和下面的形式一样，咱们只需执行git rebase -i HEAD~3，而后将两头的提交改成fixup/squash模式即可，如下图所示：

之所以是HEAD~3，是因为咱们要做的变更是基于first commit做的，因而咱们也能够写成git rebase -i a1f3929

咱们来看下更改完的commit log，如下图所示：

是不是就干掉了third commit了。
三行代码让git提交记录放弃整洁
下面咱们都是在本地的git仓库中进行的commit记录整顿，然而在理论的开发过程中，咱们基本上都是写完就间接push到近程仓库了，那应该如何让近程的开发分支也放弃记录的整洁呢？
第一种做法是在push代码前就做在本地整顿好本人的代码，然而这种做法并不适用于那种本地无奈部署，须要部署到近程环境能力调试的场景。
这时咱们只须要执行git push -f命令，将本人的批改同步到近程分支即可。
-f是force强制的意思，之所以要强制推送是因为本地分支的变更和近程分支呈现了一致，须要用本地的变更笼罩近程的。
而近程分支更新后，如果其他人也在这条分支上更改的话，还须要执行一个git pull命令来同步近程分支。
这里咱们来总结下让git提交记录放弃整洁的三行代码。
git rebase -i xxx
git push -f
git pull
复制代码

❗️❗️❗️Tips：因为rebase和push -f是有些危险的操作，因而只倡议在本人的分支上执行哦。