如何使用git管理軟件外部維護的補丁？

Question

我正在嘗試在OpenSSH（ Roumen Petrov的X.509v3實現 ）中納入社區維護的補丁以及我們自己的補丁。 據我所知，這不適合常規解決方案，因為此修補程序非常龐大，並且該修補程序的所有發行版都非常受限於OpenSSH的特定上游版本。 在修補版本之上，OpenSSH的明顯升級是純合並沖突，而這正是我要避免的，但是在Git中保持上游版本和修補版本與眾不同。

現在，我已經在Git中使用分支完成了此操作：

master
gert/develop
vendor/orig
vendor/roumenpetrov

同

• vendor/orig是一個簡單的原始OpenSSH代碼分支，每個提交都帶有OpenSSH發行版本之一，也5.9p1標簽，例如5.9p1
• vendor/roumenpetrov是從vendor/orig分叉的分支，其中應用了相應的補丁，也帶有標簽，例如5.9p1+x509-7.1
• gert/develop是基於vendor/roumenpetrov的“每日開發”分支，現在具有一些本地影響小的提交。
• master是發布就緒代碼的分支

我的目標基本上是這樣的：

• 代碼中所有更改的可檢測性。 例如：“我們已經master了6.0p1嗎？” -> git branch --contains <commit-of-openssh-6.0p1>是/否答案。
• 輕松升級OpenSSH以及Roumen的補丁程序，與本地補丁程序的沖突最少。
• View只需一次提交即可升級新版本：例如“升級到X509-7.4的補丁程序”以及“升級到新的上游6.0p1”。

實際上，我對上述模型有疑問。 假設我想從Roumen升級到6.0p1以及相應的新7.4補丁。 我該怎么辦？ 我發現以下選項：

• 升級，還原，升級，合並

  1. 在vendor/orig ，升級OpenSSH版本。
  2. 在vendor/roumenpetrov ，還原先前的提交（ git revert 12345678 7.1補丁）。
  3. 在vendor/roumenpetrov ，與vendor/orig合並。
  4. 在vendor/roumenpetrov ，應用新補丁並提交。
  5. 在gert/develop ，與vendor/roumenpetrov合並

  問題：1）需要采取許多措施，2）還原操作是單獨的提交，在讀取日志時會造成混淆（“ 6.0p1版本”->“還原X509 7.1”->“合並供應商/原件”->“應用” X509 7.4“。），3）還原以及后續的重新修補操作可能會導致超出理想狀態的沖突，對嗎？

  git log vendor/orig..vendor/roumenpetrov方面： git log vendor/orig..vendor/roumenpetrov向我展示了實際的更改，盡管列出了四個提交。

• 一樣，但是--no-commit

  1. 在vendor/roumenpetrov ： git revert -n <patch-7.1>
  2. 在vendor/roumenpetrov ： git cherry-pick -n <openssh-6.0p1>
  3. 在vendor/roumenpetrov ： git commit 神奇地將此識別為與消息中相同的提交。

  問題： git log vendor/roumenpetrov..vendor/orig顯示未應用openssh-6.0p1，因為它具有不同的提交哈希（diff = empty）。

• 合並- --squash

  問題：與上面相同，但是還有另一個原因。

• 重新設定

  問題：我們將此存儲庫推送到中央（尚未公開）位置。 因此，據我所知，如果其他人也在該分支上工作，則在新的vendor/orig vendor/roumenpetrov地上的vendor/roumenpetrov分支中重新定價是vendor/roumenpetrov 。 其他遠程分支機構也是如此。 請參閱此答案，以了解為什么我認為無法對我的案例進行重新定價。

  而且， svnpenn所說的是真的嗎？

  如果沒有重新設置基准，除了進行丑陋的合並提交，您別無選擇。

---

因此，退后一步，在這里實現此可維護性的最佳選擇是什么？ 我是否必須出於不可避免的原因而做出犧牲，因為Romen的補丁取決於特定的OpenSSH版本？ 我是否需要修改整個分支模型？ 還是我錯過了一些非常基本的東西？

Answer 1

在修補版本之上，OpenSSH的明顯升級是純合並沖突，而這正是我要避免的，但是在Git中保持上游版本和修補版本與眾不同。

我處理此問題的方法是將更改保留在單獨的分支上

A--B--C
       \
        X--Y--Z

那么如果在上游進行提交

A--B--C--D--E--F
       \
        X--Y--Z

您可以將分支重新建立到新的HEAD

 A--B--C--D--E--F
                 \
                  X'--Y'--Z'

這樣可以避免合並提交，並且如果upstream人員決定合並到主服務器，將非常容易。

參考