Question

假设我有两个分支： A 和 B A 包含文件 a.txt 和 b.txt 。
B 包含 a.txt 文件，但不是 b.txt 。这就是应该的样子。

现在我想将 A 中的更改合并到 B ，即更新 a.txt 。但是，在合并期间，我总是会遇到冲突：

CONFLICT (modify/delete): b.txt deleted in HEAD and modified in development. Version development of b.txt left in tree. Automatic merge failed; fix conflicts and then commit the result.

如何设置.gitattributes以便保留 B 的文件版本（即已删除），即 b.txt < / em>在合并期间被忽略了吗？

Answer 1

你不能。您可以在.gitattributes中设置的属性仅适用于我所谓的低级冲突，但是＆＃34;修改/删除＆＃34;我称之为高级冲突。

值得一提的是，仅仅因为 A b.txt而 B 没有，不保证您将始终获得修改/删除冲突。您获得了什么样的冲突 - 如果有的话 - 也依赖于合并基础提交。分支 A 解析为该分支的提示提交，同样针对 B ，但git merge不会仅使用这些输入。它找到了第三个输入：

          o--o--...--o   <-- A
         /
...--o--*
         \
          o--...--o   <-- B

每轮o代表一些提交。提交标记为*，这是两个分支最初拆分的地方 - 因此，现在，这是他们回归的第一个地方 - 是两个分支提示的当前合并基础

您现在运行git checkout B && git merge A。 Git将提交*与 A 的提示进行比较，并查找自b.txt以来修改的*。 Git会将*与 B 的提示进行比较，并找到b.txt。这就是产生高级别冲突的原因，.gitattributes无效。因此，您必须手动合并此文件，然后提交结果：

          o--...--o   <-- A
         /         \
...--o--o           \
         \           \
          o--...--o---o   <-- B

因为这是一个真正的合并，所以新的提交有两个父。第一个父级是 B 的前一个提示（底部的直线），第二个父级是 A 的前一个和当前提示（向上和向左）。到目前为止没什么大不了的但现在让我们对 A 和 B 进行新的提交：

          o--...--o--o--o   <-- A
         /         \
...--o--o           \
         \           \
          o--...--o---o--o   <-- B

如果我们现在再次执行git checkout B && git merge A，Git会找到一个新的合并库，通过向前搜索两个提示。从两个分支提示可以访问的第一个提交将是合并库 - 但这次，它是在顶行上的提交，特别是在最后一次合并之前的提交：

          o--...--*--o--o   <-- A
         /         \
...--o--o           \
         \           \
          o--...--o---o--o   <-- B

Git现在将针对 A 和 B 的当前提示进行差异提交*。

由于大概 B 仍然缺少b.txt，Git会得出结论：* - to-ours删除了该文件。如果您未能在 A 的两个新提交中触及b.txt，但* - 他们不会更改它。不存在高级别冲突：＆＃34; A 不变， B ＆＃34;解析为＆＃34;删除合并＆＃34;。

合并期间始终保持文件的已删除状态

1 个答案: