我正在尝试将社区维护的 OpenSSH 补丁（Roumen Petrov 的 X.509v3 实现）与我们自己的补丁结合起来。据我所知，这不适合常规解决方案，因为这个补丁很大，而且这个补丁的所有版本都非常绑定到特定的 OpenSSH 上游版本。OpenSSH 在补丁版本之上的明显升级是一个简单的合并冲突，这正是我想要避免的，但在 Git 中保持上游版本和补丁版本不同。
现在，我已经在 Git 中使用分支完成了这项工作：
master
gert/develop
vendor/orig
vendor/roumenpetrov
和
vendor/orig作为一个简单的、原始的 OpenSSH 代码分支，每次提交 OpenSSH 发行版本之一，也被标记，例如5.9p1vendor/roumenpetrov是一个分支，vendor/orig应用了相应的补丁，也被标记了，例如5.9p1+x509-7.1gert/develop作为“日常开发”分支，基于vendor/roumenpetrov，现在有一些本地低影响提交。master作为发布就绪代码的分支
我的目标基本上是这样的：
- 代码中所有更改的可检测性。例如“我们是否已经在 6.0p1 上
master？” ->git branch --contains <commit-of-openssh-6.0p1>是/否答案。 - 轻松升级 OpenSSH 以及 Roumen 的补丁，与本地补丁的冲突最少。
- 将升级新版本视为单个提交：例如“升级到补丁到 X509-7.4”以及“升级到新的上游 6.0p1”。
实际上，我对上面的模型有疑问。假设我想升级到 6.0p1 以及来自 Roumen 的相应新 7.4 补丁。我应该怎么办？我找到了以下选项：
升级、还原、升级、合并
- 中
vendor/orig，升级 OpenSSH 版本。 - 在
vendor/roumenpetrov中，恢复之前的提交（git revert 123456787.1 补丁）。 - 在
vendor/roumenpetrov中，与 合并vendor/orig。 - 在
vendor/roumenpetrov中，应用新补丁并提交。 - 在
gert/develop, 合并vendor/roumenpetrov
问题：1）要采取的很多操作，2）revert 操作是一个单独的提交，在阅读日志时会混淆（“6.0p1 release”->“revert X509 7.1”->“merge vendor/orig”->“apply X509 7.4".), 3) 恢复以及随后的重新修补操作可能会导致超过理想的冲突概率，对吧？
优点：
git log vendor/orig..vendor/roumenpetrov向我展示了实际的更改，尽管列出了四个提交。- 中
相同，但与
--no-commit- 在
vendor/roumenpetrov：git revert -n <patch-7.1> - 在
vendor/roumenpetrov：git cherry-pick -n <openssh-6.0p1> - In
vendor/roumenpetrov:git commit神奇地将其识别为与来自消息的相同提交。
问题：
git log vendor/roumenpetrov..vendor/orig显示未应用 openssh-6.0p1，因为它具有不同的提交哈希 (diff=empty)。- 在
合并
--squash问题：同上，但有另一个原因。
变基
问题：我们将此存储库推送到中央（尚未公开）位置。因此，据我所知，如果其他人也在这个分支上工作，那么
vendor/roumenpetrov在较新的分支上重新定位不是一种选择。vendor/orig这也适用于其他远程分支。请参阅此答案，了解为什么我认为重新定基不是我的情况的选择。而且， svnpenn 提到的是真的吗？
没有变基，你别无选择，只能进行丑陋的合并提交。
所以，退后一步，我最好的选择是什么？我是否必须因为来自 Roumen 的补丁取决于特定的 OpenSSH 版本而做出牺牲？我是否必须修改整个分支模型？还是我错过了一些非常基本的东西？