git - 需要修补的子模块的 git 解决方案是什么？

Question

我希望这个问题很常见，但就我的生活而言，我似乎找不到好的解决方案:

1. Project Foo 需要 third-party project Bar 的源(我无法控制)

2. Project Foo 添加 Bar 作为子模块，因为这是 Git 解决这个问题的方法

3. 事实证明 Bar 需要一些小补丁，永远不会 merge 到上游，因为它们对 Foo 非常特定

在我的理想世界中:

我可以“提交”补丁到 inside Foo 的 Bar。这是有道理的，因为这些补丁特定于 Foo，不适用于 Bar 的其他用户。

在现实世界中:

看来我必须要么提供用户每次运行的自定义脚本以修补它的 Bar 副本(痛苦且非常脆弱)，要么我必须托管(并始终保持最新)一个自定义脚本我需要的每个第三方存储库的副本(这也很痛苦，对于小补丁来说似乎有点矫枉过正，而且对于特定于 Foo 的更改似乎很奇怪)。

我应该使用什么解决方案来解决这个问题？我想这很常见，但我感觉 Git 的“解决方案”是补丁总是在上游 merge ，这是一个不可能的开始。

Answer 1

你可以，在 Foo/Bar 子模块中:

• 创建一个补丁分支，
• 将您的 Foo 特定补丁应用到 Bar，
• 将远程路径添加到您拥有的 Bar 分支，
• 将那个 patch 分支推送到那个 fork Bar 远程。

不要忘记返回 Foo，添加并提交新的 Bar SHA1(gitlink，special entry in Foo index)并推送 Foo 还有。

现在，每次你将从它的原始远程(你无法控制)更新(git fetch)Bar，将你的 patch 分支 rebase 到 Bar 的来源/主人。 (然后，像往常一样，将 Bar 推送到您的 Bar 分支，返回 Foo，添加、提交和推送)