我們現在的開發流程中添加了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。
