玩了那么多年的git了，现如今你只会add,commit,push,pull,merge，你都不好意思说你会git。chrrey-pick , filter branch, rebase等操作你还是需要盘一下的。
git rebase是干什么的呢？学者们把他成为变基。说是把很多的commit合并到一个commit中。之前，我想不明白除了把commit合并为一个以外还有什么地方会用到。几天，我确实碰到了一个现实中的问题。这个问题是出自我的博客的，我的docs由于很多次提交了，每次要合到master上都得来一次filter branch。这个操作刚开始会很快，但是随着博客内容的增多，每次去合master的时候都得走一次从头到尾的遍历，实属受不了。（读者可能并不明白我再说什么，你们也不用想明白。）
我们可以从图中看到，我首先创建了一个test文件。我们将第一行写入并置为第一次提交。之后再插入第二行作为第二行提交。现在，我想把第二次提交和第一次提交合并。这样，就不会有人再知道我曾经有过第二次提交了。这个操作就是rebase
git rebase -i HEAD~2
我们用上面的命令，就可以将最近的两次提交合并到最早的提交。之后会出现一个界面。
这个界面前两行列出了rebase所包含的commit。剩下的就是此操作的介绍。我们只需要关心pick和squash两个关键字。通过英文我们了解到，图中的意义是将第二次操作合并至第一次操作，这样在log里面只会显示一次log，然而确实是两次更改。退出即可。如果，rebase发现没有版本冲突就会直接完成rebase操作。如果有冲突，我们就像一般解决冲突一样去纠正就好，然后git add即可，不用commit，然后运行 git rebase –continue即可。 有的时候，你并不太操心rebase发生的冲突，我们可以运行git rebase –skip跳过冲突。
最后，我们还要考虑push到远端的操作。因为当前本地的版本和远端的版本不一样且不是继承版本状态。所以，系统会提示你先git pull，然后再git push。 当心，系统是好心，但如果你真像系统要求你一样去做了，那么你rebase的这些操作都会随着git pull更改为远端的版本。所以，我们在这里需要git push -f，也就是强制推送到远端不进行版本的对比。这个操作其实在多人合作的时候会产生很多副作用，让你瞬间就扮演上了小队破坏者的身份。因此，很多开发者都不建议在多人项目中用rebase这个命令，除非你和你的小队已经充分沟通过此事，而且大家也互相明白做此事的重要性，而且大家还不是新兵蛋蛋。
好了，我就记录到这里吧。