Git pull與rebase導致過度衝突。我如何解決我們的工作流程？

Question

我們有一個爲每個客戶定製的基礎系統。基地生活在自己的倉庫中，每個客戶都住在自己的倉庫中（最初是從基地克隆的）。

目標是有能力添加錯誤修復/功能到基地，可以根據需要傳播給客戶。

到目前爲止，工作流程一直如下：

• 製作犯/主題分支機構爲基本修復/特點：（上壘，主站）git commit -m "Fix admin typo"
• 合併這些變化到客戶端： （在客戶端，主人）git merge base/master。顯然，這包括解決基本和客戶定製之間的任何衝突。
• 推送合併到客戶的起源：（在客戶端，主）git push origin master
• 我們的約定一直在拉動底座（以保持歷史可讀性）。這樣的話，不同的開發商在客戶項目的工作會（客戶端，主站）git pull --rebase origin master

正是在這一點上，我們得出與拉/變基顯著的問題。開發人員在從基礎合併到客戶端後進行的pull/rebase中發生衝突。它不僅僅是一些衝突，它還有很多（對於許多正在重播的提交？），並且通常是特定開發人員甚至從未觸及過的代碼。我認爲這是不合理和不可持續的。

這裏最好的解決方案是什麼？

我唯一的想法是在拉動和處理馬虎和難以閱讀的日誌時停止使用rebase，但我寧願不必這樣做。這些客戶項目可以生存多年，而且我希望在將來能夠從基礎系統合併中解脫出來。

Answer 1

讓我得到這個直上你的回購協議：

1. 的主要項目是獨立的，叫base
2. 每個客戶的項目從base克隆，僅拉動更新
3. 的開發者從公共工作client_foo repo和push/pull往返

工作流失敗導致一個dev正在重新分配client_foo分支到base回購的新提交併推回到client_foo。這將最終打破所有其他開發者在試圖進行下一輪拉動時使用client_foo。所以你不能這麼做，並期望git自動處理它。

如果它只是每個客戶端回購的一個開發者，那麼也許這將工作。我認爲情況並非如此。

選項：

1. 繼續這樣做，你做什麼，但是當開發推動重建基礎client_foo分支（新base提交）返回公共client_foo回購，每個人都有做一個reset --hard上origin/master。如果他們將所有未改動的更改保留在私人主題分支中，則他們必須將rebase返回到新的client_foo/master。

2. 讓您的開發merge從base更改爲client_foo。這會給你一個client_foo合併提交，你說你試圖避免，但它會給你最準確的歷史。當你的開發者進行「拉回」時，你不應該再收到你現在擁有的長長的衝突列表。

3. 讓您的dev cherrypick從base變更爲client_foo。這會保持你的歷史線性，但git將不再跟蹤cherrypick'd提交來自base。你必須想出另一種方式來追蹤它。

我會說堅持＃2，因爲這是git應該工作的方式。但是，別人可能會想到一個更好的非顯而易見的解決方案。