2019獨角獸企業重金招聘Python工程師標準>>>

此小結為什麼說是簡單解析呢，因為rebase和merge的選擇問題討論比較激烈，筆者也沒有一個定論，而且git也處於研究發展階段，很多理論還沒有完全的純熟。

對於一個多人開發團隊頻繁提交更新的情況，如果使用merge會使得歷史線圖非常複雜，並且merge一次就會新增一個記錄點，如果使用rebase就是完全的線性開發。

上圖所示是Merge和Rebase的兩個結果，顯然你不想要merge的混亂結果吧，你能告訴我merge圖中那條線是master分支嗎？

所以給出如下建議，如果同一檔案反覆修改或提交次數比較多，預期會出現很多的conflict，那麼可以使用merge合併，僅需要解決一次衝突即可（不過，大範圍主題式的修改，是不是應該事先就新開一個分支呢？）；如果修改範圍小，預期conflict少，則建議使用rebase。

EGIT中預設的pull操作是Fetch+Merge，如果要用rebase，可以分開操作。先執行Fetch更新remote tracking，再執行rebase進行合併（下一小節將介紹rebase操作）。或者修改pull的預設操作，在.git/config檔案中配置：

上述配置只對mirror分支有效，也可做全域性配置，在$HOME/.gitconfig中配置，windows系統如果沒有配置HOME變數的話就預設在$documents and settings/ USER目錄下：

轉載於:https://my.oschina.net/91jason/blog/406707