如何將更改推送到具有沖突歷史記錄的git倉庫？

Question

我想擁有一個受祝福的存儲庫和幾個組或開發人員存儲庫。

開發人員應從克隆的存儲庫中的受祝賀的存儲庫工作中克隆並提交其更改。 每當他們覺得他們的工作已經完成時，他們就應該將他們的更改推送到他們的公共存儲庫。 然后，主要開發人員應從公共開發人員存儲庫中提取更改 - 執行他想要做的任何事情（簽名，修改等），然后將其推送到受祝福的存儲庫。

在任何代碼審查計數代碼可能被拒絕的環境中。 假設開發人員A和B同時處理某個功能。 兩位開發人員都完成了他們的工作並將補丁推送到他們的公共存 當開發者B的補丁被拒絕時，開發者A的補丁被接受。 然后，首席開發人員將開發人員A的更改推送到祝福的存儲庫。 開發人員B修復補丁並將其工作重新放在受祝福的存儲庫之上（分別是開發人員A接受的更改）。 如果開發人員B現在將他的工作推送到他的公共存儲庫，他將收到一個錯誤，即存儲庫具有不兼容的歷史記錄。

我可以解決的唯一方法是刪除公共存儲庫並重新創建存儲庫。 有更清潔的方法來解決這個問題嗎？

Answer 1

考慮到公共回購只為客戶提供集成經理，B可以安全地強行推動他的工作：

git push --force

集成管理器還沒有接受任何B的提交，所以B可以重寫他的提交歷史並再次推送它們。
是否有人會從B的公共回購中克隆/拉出，然后push --force將不被視為可接受的解決方案。

---

OP Alex在評論中補充道：

所以我做對了嗎？ 如果有人從B拉出來，工作流程就會被打破，因為受祝福的回購不是B的嚴格有序子集？

我回答：

如果其他任何人從B的公共回購中撤出，那么該歷史就會變成公開的（它不在您的場景中，因為只有集成管理器才會撤消，甚至不會保留B的提交）。
你不應該改變公共歷史。 請參閱Pro-Git書籍“重新定位的危險 ”部分

所以，如果我有一個修補程序推送到受祝福的回購我會殺死我的公共回購中的所有東西，盡可能接近受祝福的回復？ 或者如何領導櫻桃挑選修補程序？

如果您的公共hot_fix還有其他尚未被接受的東西，您可以在專門的' hot_fix '分支中發布您的修補程序（B首先在祝福倉庫之上重新定位，然后推送到B的公共倉庫），由集成管理器監控。

無論如何，重點是：集成管理器總是期望在他現有的提交集， 新歷史記錄之上進行新提交，而不是相互沖突的歷史記錄（因為缺少來自B的變更）。
無論分支的起源如何，任何沖突的歷史都應該被拒絕。

並提防櫻桃采摘，它可能導致麻煩。 看到：

• “ 在Git中，你如何將bug修復提交給其他更新的分支？ ”
• “ 在多個分支中做一個git櫻桃挑選 ”

Answer 2

您可以使用push -f強制更新遠程來隨意更改公共存儲庫中的歷史記錄。 由於個別開發人員是唯一應該更改自己的公共存儲庫的人，因此這通常是安全的事情。