Pull Request

我们现在的开发流程中添加了review的流程，目前是依赖Pull Request来进行review。不得不说没有整理过的Pull Request在review的时候相当痛苦：
1.一个Pull Request中可能包含几十个commit，内容非常多。
2.可能有多个commit修改同一个文件，按commit查看时难以读懂，例如早些的commit做了一处错误的修改，晚些的commit又修复了这个问题。
3.有很多无效的commit，例如忘记修改版本号的补充，清理log代码的提交。
4.混乱的commit，合并的时候产生冲突，解决冲突重新提交后就变成了一个commit，完全不知道这个commit中包含了哪些改动。

我们应该有效的管理我们的提交，在开发期间commit自然越细碎越好，每个小功能点的修改做一个单独的提交对代码有助于代码合并。在合并时应该对commit节点进行整理，对同一个模块修改的多个commit应该合并成一个并写好描述，同一个分支的代码在合并时应该调整成顺序连续，方便回滚。

下面是几个有用的命令：

git rebase

关于rebase命令的基本用法详见：http://gitbook.liuhui998.com/4_2.html
rebase命令的主要作用是在合并的时候调整commit节点的顺序。
例如我们从develop分支拉出了一个featureA分支进行开发，等开发完毕时，develop分支已经合并了其它feature分支的提交。如果直接使用merge命令，合并完之后的节点按时间顺序排列，很可能是混杂在一起的，假如需要回滚代码十分的不方便。使用rebase命令合并会使featureA分支的所有节点在合并后仍是连续的，对回滚代码十分方便。
rebase还有交互模式，使用rebase -i可以进入交互模式。交互模式下可以灵活的对节点进行合并，在编辑界面中使用squash和fixup可以将节点合并到前一个pick的节点。交互模式的具体用法可以参考：http://chuansong.me/n/447693

git merge --squash

如果当前开发分支featureA包含的内容很简单，比如修复了一个bug，但是产生了多次提交。那么也可以在merge的时候添加squash参数，这是rebase的简单粗暴版，将featureA上产生的提交合并成一个节点。尽管效果上和rebase类似，但是原理并不一样，merge --squash的时候是将featureA分支上的改动全部摘过来，需要自己重新commit。