合并导致合并冲突到我没有改变的文件

Merge results in merge-conflicts to files I didn't alter

我已经使用 SAP's OpenUI5 repository 的一个分支工作了一段时间,并且想合并来自另一个(更新的)发布分支的最新更改。 本质上,我想"upgrade"我的叉子。

我的分叉点是 aa08b45865b8db4457bc6c626754c58230811b43,它指向 rel-1.28 发布分支可访问的提交。

我从发布分支开始我的 "fork",而不是 master,因为我担心 master 的工作会不稳定并且提交会与多个版本重叠。

我的升级目标是1.34.6,由cb4d1be36087ed7f1dfbde44884782774fceb51b指向。

我需要 运行 的最终命令实际上是:

git checkout aa08b45        # my original fork-point
git checkout -b myForkPoint # local branch
git merge cb4d1be           # merge in 1.34.6 code

但这会导致许多我没有更改的文件的合并冲突。 (我猜是因为我正在尝试合并我的 HEAD 无法访问的 ref)。

使用 merge-base 并在发布分支和 master 之间手动比较提交(例如 63596f and b23117),OpenUI5 的发布分支似乎由 cherry-picking 提交填充master。发布分支未合并回 master 一个,它们已完成更新。

git merge-base --is-ancestor aa08b45 origin/master; echo $?; # prints 1
git merge-base --is-ancestor cb4d1be origin/master; echo $?; # prints 1

那么,也许这种分支模型不利于处理 public 发布分支?

无论如何,有没有一种干净的方法来 "upgrade" 我的叉子?

这里的答案是创建我们自己的合并基础,方法是将两个发布分支合并在一起,并让后来发布的 (1.34.6) 一方赢得所有冲突(使用合并策略)。

然后,将该合并基础合并到我们自己的分叉分支中。

这样,每个发布分支的内容都可以从我们的分叉点访问,因此第二次合并的所有冲突都只会来自我们引入的更改。

步骤如下:

# first create the merge-base
git branch merge-1.34.6 1.34.6
git checkout merge-1.34.6
git merge rel-1.28 -s ours 1.34.6

# next merge the merge-base branch into us
git checkout myForkPoint
git merge merge-1.34.6
...fix conflicts, stage and commit...