Keywords: rebase, Git, 变基, 衍合

rebase 的概念/作用其实很简单——就是「变基」。具体来说，就是改变一条分支的「基点」，使原分支从指定的地方（commit）重新长出来。并且，由于是一条新分支，你可以随意修改其中的 commits，也就是——重写分支历史。

而 rebase 的主要目的即删繁就简。

下面讲下关键步骤：

git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] [<upstream> [<branch>]]
git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>]
git rebase --continue | --skip | --abort | --edit-todo

所有 rebase 的操作对象都是 commit。（你可以 rebase 一个分支 git rebase -i branchX，但实际上还是作用于该分支最新的 commit。）

以这个 commit 为「新基点」发起 rebase 后，会打印出一篇 commit 历史让你修改。

其中最常用的修改就是把 commit 前的 pick 改为 s (squash, /skwɔʃ/, 意为挤压)，作用为保留该 commit 作出的修改，但删去该节点，只给它一个留名的机会。(用专业的话讲就是——不保留待合并分支上的历史信息，也不提交、不移动HEAD。）多个以 s 为前缀的 commit 最终会整合成一个 commit，各个 commit 的描述部分也被整合到一起。

而最终极的修改就是直接删去 commit(s) ——篡改历史。这也就意味着，对应的改动也一并灰飞烟灭。（所以为什么说 rebase 是个危险的操作，就是因为篡改了历史！想想如果别人基于你国正史 fork 了一条分支，而你日后竟变基了会发生什么吧！）

改完之后 :x（Vim下的保存退出命令），Git 就去检测冲突了，此时类似于合并。
合并将按你留下的 commit(s) 重演历史，你可以修改每一次 commit 的具体代码。而如果你不是为了修改，只是为了简化树……我的办法是只留下一条 commit，用最新工程完全覆盖来解决冲突。（不知有没有更好的方法）

冲突解决完后 git rebase --continue，你就可以正式「书写」历史啦——撰写新的 commit 描述。这时那真是，想怎么写就怎么写~

这般本地 rebase 完成后，记得 git push -f，-f 用于强制将新历史推送至远程仓库。
至此，rebase 就彻底结束了。

看看你新造的树吧，是不是特简洁，特优美？（如果不是……你 rebase 干嘛……）

当一个系统的专有名词（黑话）足够多，就创造了文化。

Welcome to GitLand~