如何保證在多人協作的時候git的提交記錄是一條直線？

01-16

之前翻譯的一篇文章講的非常清楚，關於代碼合併時Merge和Rebase的選擇。 @Jack Mi

你要知道的第一件事是，git rebase 和git merge 做的事其實是一樣的。它們都被設計來將一個分支的更改併入另一個分支，只不過方式有些不同。

rebase最大的好處是你的項目歷史會非常整潔。首先，它不像git merge 那樣引入不必要的merge commit。其次，rebase導致最後的項目歷史呈現出完美的線性——你可以從項目終點到起點瀏覽而不需要任何的Fork。這讓你更容易使用 git log 、git bisect 和gitk 來查看項目歷史。

不過，這種簡單的commit歷史會帶來兩個後果：安全性和可跟蹤性。如果你違反了Rebase黃金法則，重寫項目歷史可能會給你的協作工作流帶來災難性的影響。以及rebase不會有merge commit中附帶的信息——你看不到feature分支中併入了上游的哪些更改。

詳細閱讀：5.1 代碼合併：Merge、Rebase的選擇 · geeeeeeeeek/git-recipes Wiki · GitHub

拓展閱讀：Home · geeeeeeeeek/git-recipes Wiki · GitHub

Stars are welcomed

rebase

你不覺得有多個分支各種合併，然後用git log --gragh看到的圖像很美么？

用 rebase 代替 pull 應該可以保證吧

用patch、rebase、cherry-pick等方式都可以

建議搭一個gerrit

儘管我個人覺得沒有必要保證一條直線那麼潔癖……

開兩個git repo，開發和發布分開。

rebase可以。建議分支合併到主分支時還是merge，這樣比較符合開發的流程