我有ignoring files during merge的特殊情况。
假设我有两个分支: 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>在合并期间被忽略了吗?
答案 0 :(得分:0)
你不能。您可以在.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;。