Git rebase -i 交互变基，体验艺术般的命令

  上篇的Git之反悔中，最后提到用git reset做一些反悔的动作，有没有发现一个问题，那就是我前期做的工作都浪费了，要重新提交，要是需要后悔的操作在第十个呢，尼玛还要不要玩，今天就是以这个事情为出发点，体验下git rebase -i艺术般的操作

git rebase -i 交互变基在项目中的使用(可以用来删除一些无用提交，可以对某一个问题提交聚集在一起甚至合并，可以交换提交的顺序) ，请仔细看几遍它的作用。现在我回答上面的问题，如果我要后悔的操作在第十个，那么我可以用git rebase -i来交换顺序，把第十个提交交换到第一个提交 ，这样我就能用git commit --amen来操作了，这不失为一种有效的方法。

     

可是呢再想想，我完全可以先把遗漏的东西先提交了，再用git rebase -i来进行合并呢，这样不是更省事！对，没错，完全可以这样搞。 

下面举个例子， 排序、编辑提交信息、删除无用提交，合并同问题提交，这些功能应该覆盖了它所应该发挥的效果吧，当然，你可以自己心情发挥。

初始化的样子：

 现在要去掉第二个提交，合并3.4.5提交,重新修改第五个提交。那么现在目的很明确，我们需要对前6个做修改，所以我们要用到第六个Log信息的commitId，这将会在git rebase -i中用到，这点很重要。

      现在使用git rebase -i b1v38d5, 不过可能啊，系统会提示你一些信息，说你的工作区不干净，我这里可以说下该怎么办，具体的更多的功能这里不做说明 。

现在我们可以用git stash save "need to restore" ,来保存工作区，然后执行git rebase -i，先上个图。

当然这个图不是刚使用命令的图，刚使用命令的时候 ，所有的信息都是pick XXX,跟第四行一样。

解释几个事情 ，这个界面的Log信息和我们使用git log出现的顺序是相反的，所以我后面说的的第几个都是按照git log的顺序的。

另外，稍微解释下pick、reword、edit、squash、fixup的含义。

pick就是cherry-pick

reword 就是在cherry-pick的同时你可以编辑commit message，它会在执行的时候跳出一个界面让你编辑信息，当你退出的时候，会继续执行命令

edit 麻烦点，cherry-pick同时 ，会停止，让你编辑信息，完了后，你要用git rebase --continue命令继续执行，相对上面来说有点麻烦，感觉没必要啊。

squash，合并此条记录到前一个记录中，并把commit message也合并进去 。

fixup ，合并此条记录到前一个记录中，但是忽略此条commit message

其实啊，我们可以稍微想象下，这个pick是不是类似cherry-pick的翻版，其实是一个道理的。 还记得我们在使用这个命令的一个目标吗，我们要删除第二个提交 ，就是那个add wei那条信息，所以嘛，在这里，我们删除了pick add wei，那一条，这样它就不cherry-pick那条了。 好了，我们现在要合并3、4、5，这个时候我们把4、5前面的pick改为f，也就是说4、5被合并到3中了。 这三条实合并了，我们需要重新修改3 的信息，那么我们在3上，把Pick改为r ,因此就出现上图的界面 ，不要说我只说不上图，哎，动手更清楚 ~！

这些准备工作都搞定了，然后按照界面的提示，Ctrl+x，按y保存退出，这个时候就开始合并了，可能不同版本的git 会有不同的提示，我这里可以给出一个提示界面。

好了，是不是很有艺术的感觉 ，当然 ，前提你要有欣赏的细胞，开个玩笑~

现在我们来总结下，这个命令能给我们提供什么便利

1、当我们掉换顺序的时候 ，我们可以配合使用git commit --amend来补充提交 。

2、当我们觉得哪个提交没有用，想用git revert的时候 ，我们可以这样做，可以显得很美观，right~?

3、同一个问题，如果我们有多次提交 ，那么我们可以选择合并，让同事可以看得更清楚，方便修改问题~

事物总有相对性，有好也有坏，列举下吧

1、当我们用了这个命令后，所有被我们重新cherry-pick的commit的hash值都会变，这意味着，对远程分支不能进行快进式的提交，这个时候你就需要覆盖远程分支了，git push origin -f  local_branch:remote_branch，强制覆盖，不留痕迹。

2、如果你这个分支是公共的分支，请不要随便用git rebase，因为大家都要Merge你的分支，在的用这个命令之前 ，其它分支merge了你的分支，在你使用这个命令做了合并一些的操作后，其它分支又merge一次，就是出现相同的提交 。 所以，如果你维护的是自己的私有分支 ，你完全可以随便搞，但是只要你的分支要被公开 ，那就按照一步一步来吧。

好了，今天就到这里了，哎，艺术也是很累的，有写的不好的随时欢迎沟通~