如何在git合并中强制使用公共祖先？

假设我有一个名为

master

的分支和一个名为

upstream\u lib

的分支

分支

master

有一个子目录

lib

，该子目录基于分支

上游_lib

上的代码；

上游库

中的更改会定期合并（使用子树策略）到

主

分支。

master

中的

lib

目录有一些自己的修改，这些修改不在

upstream\u lib

中

但是，假设这两个分支没有共同的历史记录（例如，因为存储库刚刚迁移到git），或者合并库不正确，因为上游库中的合并已被挤压，存在一些重定基或其他情况

---

问题是：在<代码>上流→LIB < /代码>的一组新的变更中，如何迫使合并作为一个共同的祖先来考虑：<代码> UpStudioLIB < /代码>？< /P> < P>我从未使用过<代码>子树< /代码>策略，所以这可能是一个次优的解决方案（也许它不起作用^ ^），但是您可以将

上游库

中的所有新提交应用于

主行

的临时分支，然后合并该分支。我所想的并不能从根本上解决您的情况，因此每次您想要引入新的更改时，都必须进行这种“手动合并”，但其工作原理如下：

确定

master

祖先行中的伪共同祖先，比如

master~100

确定

上游库

行中的伪共同祖先，例如

上游库~150

制作

上游库

分支的一次性副本：

git分支--无轨道新上游库上游库

使用带有子树选项的递归策略，将

新的上游库

重设为

主库~100

。（我不认为您可以只使用子树策略，因为正如您所说，

master

中的

lib

目录有自己的更改。）下面是一个完全未经测试的命令：

git rebase -s recursive -X subtree=lib --onto master~100 upstream_lib~150 new_upstream_lib

请注意，

new\u upstream\u lib

现在包含整个

master

树，即使您只关心

lib

目录

合并它：

git签出主机和&git合并新的上游库和git分支-d新的上游库

---

我想唯一的问题是上游库分支没有共享历史或提交，但我可以接受。很高兴听到这个消息！如果您想强制共享祖先，您可以创建一个初始的空提交，并将

master

和

upstream_lib

重新设置到该祖先上。当然，假设

上游_lib

是您自己的分支，而不是远程分支。但是，如果最初将

upstream_lib

导入

lib

目录只是一个

cp

而不是一个合并（如中所述），您仍然会遇到您描述的问题。