有人能解释一下这个有趣的 git 合并行为吗
我有两个分支，
A-C (master)
\
B-D (clean)
在 A..C 中我添加了一个包含一堆文件的目录。在 A..B 中，我添加了完全相同的目录和文件，这样 git diff C..B 显示该目录中没有任何更改。在 B..D 中，我对这些文件进行了更改。我想将这些更改合并到 master 中。我尝试了两种不同的方法，一种工作得很好，另一种则严重崩溃：
git merge clean
上面的命令创建了大量的冲突，实际上每个文件都有冲突。
git merge clean^
git merge clean
上面的工作完美，递归合并，根本没有冲突。
上述情况如何以及为何发生？ git 不能查看历史并确定这是早期分裂吗？或者说，将其用作合并策略可能会带来太大的负担吗？
I have two branches,
A-C (master)
\
B-D (clean)
In A..C I added a directory with a bunch of files. In A..B I added the exact same directory and files, such that git diff C..B shows no changes in this directory. In B..D I did changes on those files. I want to merge those changes into master. I tried two different approaches, one worked cleanly and the other broke insanely badly:
git merge clean
The above command creates a tonne of conflicts, conflicts on every file in fact.
git merge clean^
git merge clean
The above works perfectly, merges recursively, no conflicts at all.
How and why does the above happen? Can git not look at the history and determine that it was an early split? Or would that be too potentially taxing to be used as a merge strategy?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在第一种情况下，
git merge clean，Git 对于作为合并基础的冲突文件没有共同的祖先，因此看起来您正在尝试将两个都创建了相同内容的树合并在一起文件名相同但内容不同。 （共同祖先 A 没有任何冲突的文件。）在第二种情况下， git merge clean^ && git merge clean，第一次合并再次没有看到共同的祖先，但能够轻松解决它，因为文件是相同的。然后，第二次合并可以采用现在已知的祖先，并仅应用差异。
In the first case,
git merge clean, Git has no common ancestor for the conflicting files upon which to base the merges, so it looks like you are trying to bring together two trees that have both created the same filenames but with different content. (The common ancestor A does not have any of the files that are conflicting.)In the second case,
git merge clean^ && git merge clean, the first merge again sees no common ancestors, but is able to trivially resolve it, because the files are the same. The second merge then can take the now-known ancestry, and just apply the diff.