聊下 git rebase -i

在使用git作为源代码管理工具的时候，开发的时经常会面临一个常见的问题，多个commit 需要合并为一个完整的commit提交。

在一个基本的迭代周期里，你会有很多次commit，有跟配置文件相关的，有跟代码相关的，甚至有跟下次发布fixbug相关的。这些都是你在完成本地开发的时候一个变化记录而已。但是当你需要将你的迭代项目作为一次发布提交时就需要整合所有之前提交的那些很零碎的commit。

根据基本规范，你的commit应该类似"release：20161023_imageprint"，在此commit里应该是完整的提交。

合并多个commit为一个完整的commit

我先基于develop主分支拉出一个功能分支（每个人和每个公司对分支的管理都不太一样，这里不需要太纠结。）。这里的develop是开发主分支，所有的开发功能代码都需要回归到这个develop分支中去。

git branch -a –vv

develop_fixbug_imageprint 分支是我基于远程develop分支拉出来的开发分支，我会基于这个分支来fix一些bug。我们分别看下develop、develop_fixbug_imageprint  commit log。

git checkout develop

git  log

git checkout develop_fixbug_imageprint

git log

develop_fixbug_imageprint的commit log是和devleop commit log 一模一样。我们现在切换到develop_fixbug_imageprint进行一些操作。

添加一个1.txt文件，然后git add . ，git commit –m’add 1.txt’。

再添加一个2.txt 文件，然后git add . ，git commit –m’add 2.txt’。

现在develop_fixbug_imageprint分支里有两个commit。这两个commit都是为了fix当前这个bug而做的两个提交。现在我们要合并代码上主develop分支。总不能把这两个commit直接提交上去，这里还好只有两个commit，但是一般项目开发周期两个星期的话，你起码有十几个commit。那这样提交上去之后就很难管理和跟踪。（我以前都是这样干的，现在发现这样不好跟踪管理。）

那么我们如何完成这个合并commit尼，就需要用到git rebase 命令。

先来解释下git rebase 。你其实可以把它理解成是“重新设置基线”，将你的当前分支重新设置开始点。这个时候才能知道你当前分支于你需要比较的分支之间的差异。

比如，develop_fixbug_imageprint分支是来自develop分支，那么从test commit开始后面我们基本上都是各自发展，现在在develop_fixbug_imageprint分支上有两个commit，我们需要找一个基准，这个基准就是git需要找到哪些是你后来提交的commmit，总的有个参照。

git reabse –i develop

git rebase 立马知道develop与develop_fixbug_imageprint之间的差异。因为我们是基于develop设置rebase的。git rebase –i ，这里的”-i“是指交互模式。就是说你可以干预rebase这个事务的过程，包括设置commit message，暂停commit等等。

这里我们要求很简单就是合并之前的commit且重新设置commit message。

我们设置第二个”pick 657a291 add 2.txt” 为” s 657a291 add 2.txt”这里的s就是squash命令的简写。

跳出来了一个临时文件，最上面是两行commit message。我们修改下这个总体的commit message。

删除之前的两条message(ESC dd)，设置一总的message 然后保存退出。(ESC wq)

我们查看下log。git log

是不是没有了之前的两个commit。

原理很简单：rebase需要基于一个分支来设置你当前的分支的基线，这基线就是当前分支的开始时间轴向后移动到最新的跟踪分支的最后面，这样你的当前分支就是最新的跟踪分支。这里的操作是基于文件事务处理的，所以你不用怕中间失败会影响文件的一致性。在中间的过程中你可以随时取消rebase 事务。git rebase –abort

在进入git rebase –i 交互模式，你可以做的事情就很多了，可以设置edit 编辑commit 内容，可以让他暂停commit操作。等等。