我希望这个问题很常见,但就我的生活而言,我似乎找不到好的解决方案:
Project Foo 需要 third-party project Bar 的源(我无法控制)
Project Foo 添加 Bar 作为子模块,因为这是 Git 解决这个问题的方法
事实证明 Bar 需要一些小补丁,永远不会 merge 到上游,因为它们对 Foo 非常特定
在我的理想世界中:
我可以“提交”补丁到 inside Foo 的 Bar。这是有道理的,因为这些补丁特定于 Foo,不适用于 Bar 的其他用户。
在现实世界中:
看来我必须要么提供用户每次运行的自定义脚本以修补它的 Bar 副本(痛苦且非常脆弱),要么我必须托管(并始终保持最新)一个自定义脚本我需要的每个第三方存储库的副本(这也很痛苦,对于小补丁来说似乎有点矫枉过正,而且对于特定于 Foo 的更改似乎很奇怪)。
我应该使用什么解决方案来解决这个问题?我想这很常见,但我感觉 Git 的“解决方案”是补丁总是在上游 merge ,这是一个不可能的开始。
最佳答案
你可以,在 Foo/Bar
子模块中:
- 创建一个
补丁
分支, - 将您的
Foo
特定补丁应用到Bar
, - 将远程路径添加到您拥有的 Bar 分支,
- 将那个
patch
分支推送到那个 forkBar
远程。
不要忘记返回 Foo
,添加并提交新的 Bar
SHA1(gitlink,special entry in Foo
index)并推送 Foo
还有。
现在,每次你将从它的原始远程(你无法控制)更新(git fetch)Bar
,将你的 patch
分支 rebase 到
。 (然后,像往常一样,将 Bar
的来源/主人Bar
推送到您的 Bar
分支,返回 Foo
,添加、提交和推送)
关于git - 需要修补的子模块的 git 解决方案是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40755939/