我們的R & D與兩個中央回購站合作，最初由非常頑固的智能人開始，一個與rebase合作，另一個與gitflow和merge合作。儘管我在使用合併時非常舒服，並且我發現大多數github項目都使用這種模式，但隨着我們轉向更有組織的Gerrit代碼審查系統，許多開發人員正在向我們從其他團隊回購。將團隊從Git Merge切換到Rebase
所以現在是這樣的：我被man頁面警告過，永遠不要混合重新綁定和合並，現在我必須切換整個團隊。我想知道如何做到這一點，沒有太多的風險，我們的代碼的穩定性。人們總是有一個開放的功能分支或兩個，並在開發過程中可能會從開發多次合併。這樣的功能分支是否可以切換到重新綁定，或者是否應該在所有功能分支先合併並且沒有分支存在並且自叉的歷史合併到他們的歷史記錄之後纔開始截止日期？我如何規劃這個平穩過渡？
在我看到的混合合併和重新綁定中的主要問題是，當你做一個rebase時，它會將歷史「線性化」，而這對於合併提交併不能很好地工作。但線性化本身實際上具有其自身的優點，因爲歷史變得更簡單並且更容易推理。
最簡單的策略是確實避免合併。在此之前，人們會早些說git merge X而不是git rebase X。
這並沒有那麼糟糕，除非在本地分支中有多個提交，並且其中一個提交了rebase時的合併衝突。進一步提交到同一個地點可能會一次又一次地產生相同的合併衝突。在這種情況下，解決方法可能是中止重新分配git rebase --abort並重新排列本地提交git rebase --interactive或壓縮本地提交（git reset $(git merge-base HEAD X)）。之後重複rebase。
在進行rebase之前應特別注意共享分支機構。重訂那些在人力同步將是必需的，許多人可能會傾向於避免不惜一切，見下圖：
另一種方法是接受合併從上游開發過程中和合並後/讓拉之前做壁球請求，例如：
git checkout -b Work
#work...commit...commit..
git merge X
#work...commit...commit..
git merge X
git reset X && git add . && git commit -m 'All my work squashed'
#alternatively the last part might be like this:
git checkout X && git merge --squash Work
這種方法的好處在於，你可以有這樣的分支沒有人際交往的開銷相對安全地共享信息。在合併兩個分支時解決衝突通常比在另一個分支上重放一個分支時更容易。
我認爲你需要理解並使用merge和rebase來使用git（特別是在gerrit中）。
一些例子...
你會當你提升你的功能分支到一個新的遠程主合併。這提供了最小的提升工作，並且很容易遵循例如gitk的功能開發歷史。
git fetch
git checkout origin/my_feature
git merge origin/master
git commit
git push origin HEAD:refs/for/my_feature
當你準備送你將合併提交（與因爲沒有合併提交被允許在master--squash選項）。
git fetch
git checkout origin/master
git merge --squash origin/my_feature
git commit
git push origin HEAD:refs/for/master
當交付承諾你會失敗，重訂無論出於何種原因集成和你需要更新它推向一個新的遠程主。
git fetch
git fetch <gerrit link>
git checkout FETCH_HEAD
git rebase origin/master
git push origin HEAD:refs/for/master
P.S.希望你們在考慮轉向Gerrit時知道你在做什麼。 –
我希望我對此有發言權，這是一家重要的國際公司，我們從上面獲得了這一要求。到目前爲止，我們一直在使用Atlassian Stash，但我們需要稍微嚴格的代碼審查規則。在某些情況下，Gerrit可能是一種矯枉過正的情況，那是你的建議？ – Ira
根據我的經驗，Gerrit傾向於成爲一種失能而非啓用工具。 –