代码之家 › 专栏 › 技术社区 › creativename

Github pr squash导致错误的合并冲突

merge github git

creativename · 技术社区 · 7 年前

我想知道这是否是一个Github bug,我想知道是否有其他人看到过这个问题。我有 master , dev 和 feature 我的Github回购中的分支。

过程通常如下:

master : A
dev    : A 
feature: A - B - C

然后我合并 特征 进入之内 DEV 删除 特征 分支,但我不会挤压以保留所有提交历史记录:

master : A
dev    : A - B - C

当我融入 主人 我挤压合并使其看起来更干净:

master : A - BC
               \
dev    : A - B - C

我明白 BC 在这一点上更像是一个单独的提交,但是 主人 代码 公元前 和 DEV 代码 C 是一样的。

当我比较 主人 和 DEV 在上面的阶段,当我试图合并时,我看到很多冲突 DEV 进入之内 主人 或者反之亦然。

冲突不会改变我是否要合并 DEV 进入之内 主人 或 主人 进入之内 DEV ;例如,如果 dev -> master 代码差异是 -a and +b ,当我尝试合并时,我会看到相同的区别。 master -> dev 不是 -b and +a .

我们希望继续在 DEV 分支并保留其历史记录,因此删除它并基于 主人 不会是一个选择。

我正在使用Github挤压合并,因为其他成员需要在合并到之前批准这些更改 主人 .

有人能解释我为什么看到这个问题以及如何解决它吗?

1 回复 | 直到 7 年前

torek 7 年前

此图:

master : A - BC
               \
dev    : A - B - C

意味着两者之间有某种联系 C 和 BC .

没有这样的联系,但是是之间的联系 A 和 B (特别是从 乙 回到 一 )因此,更准确的绘图是:

A--D   <-- master
 \
  B--C   <-- dev

哪里 D 有一样快照作为 C ,但不相关,因此该名称 D .

这是整个问题的根源:

当我试图合并时,我看到很多冲突 dev 进入之内 master 或者反之亦然。

就Git而言, DEV 和 主人 通信是提交 一 . 因此,Git必须从 一 到 C 再把它应用到 主人 但吉特的眼睛也没有 乙 或 C 然而。

我们希望继续在 DEV 分支并保留其历史记录,因此删除它并基于 主人 不会是一个选择。

在这种情况下,停止做壁球,因为壁球有效地“杀死”了一个分支:你不应该对 B-C 提交。做一个真正的合并。在Github Web UI中,选择“合并”将执行此操作;在命令行中,使用 git merge --no-ff . 而不是一个全新的完全独立的承诺 D ,您将获得合并提交(我仍将调用它 D ):

A------D   <-- master
 \    /
  B--C   <-- dev

当你做更多的工作时 DEV 你得到:

A------D   <-- master
 \    /
  B--C--E--F   <-- dev

现在你可以再进行一次合并。这次没有必要 --no-ff 尽管它仍然可以正常工作;在Github Web UI上,也没有什么可更改的。您将获得一个新的合并提交 G :

A------D-----G   <-- master
 \    /     /
  B--C--E--F   <-- dev

第二次合并的输入是commit C 作为合并基础,提交 D 作为 --ours 并提交 F 作为 --theirs ,合并将顺利进行。和以前一样,快照 C 和 D 将匹配,快照位于 f 和 G 将匹配。

如果你想从 主人 ,用途:

git log --first-parent master

这个导演 git log 只看第一每个合并提交的父级。也就是说,Git将首先显示您提交 G , to which 主人 点。然后它会从 G 给它的第一个父母 D ,并显示该提交。然后它会从 D 给它的第一个父母 一 并表现出承诺。因为之前根本没有承诺, GIT日志 现在停止,工作完成。

(当然,如果之前 一 , GIT日志 会继续展示,但这里的所有图纸之前都没有承诺 一 )