仅由一个分支更改的文件上的 Git 合并冲突答案

【问题标题】：Git merge conflicts on files that are changed by one branch only仅由一个分支更改的文件上的 Git 合并冲突
【发布时间】：2018-03-01 18:43:38
【问题描述】：

我在http://github.com/ohcibi/prezto 有一个 zprezto 的分叉

重现我的问题：

git clone http://github.com/ohcibi/prezto
cd prezto
git checkout ohcibi（我有一个叫这个名字的分支，这里没有错字！）
git merge master
显示一堆冲突

提交日志显示ohcibi 中只有 3 个提交是自 4 月 26 日左右的最后一次合并提交以来的新提交。所有 3 次提交都没有触及任何冲突的文件（除了一个预期会发生冲突的文件）。

但是为什么合并在其他文件甚至.gitmodules 上也会发生冲突？

注意：我不需要帮助解决合并冲突！我知道该怎么做，我故意没有在那个问题中添加git-merge-conflict-resolution-tag，因为它是一个错误的标签（所以它不会丢失，不要添加它！）。我想知道为什么首先会发生这些冲突（鉴于冲突文件在两个分支中都*没有*更改，这是我知道的合并冲突的常见原因）。 p>

【问题讨论】：

那么这些其他文件在两个分支中真的相同吗？空格或行尾甚至会有所不同吗？我看到冲突出现在各种我没想到的地方。
恐怕您没有仔细阅读问题。 ohcibi 分支独有的 3 个提交不会以任何方式操作相关文件。因此，即使它是由某些空格引起的，ohcibi 中也必须有添加这些空格更改但没有的提交。我重复一遍：冲突的文件没有被其中一个分支触及。实际上可以通过克隆存储库并显示提交日志来验证这一点 (git log --graph --decorate --all)
ohcibi - 126 次提交和 136 次在 master 后面提交 3 次提交有什么区别？
您是否查看了每个版本中三个文件之间的差异？
@TimBiegeleisen 3 次提交.. 不是 3 个文件... ....

标签： git git-merge

【解决方案1】：

Git 使用树上的三个点来合并，即分支的头部、要合并的分支的头部以及两者的最近共同祖先。如果有疑问，您可以运行 merge-base 管道命令来找出 git 在最近的共同祖先处看到的提交。

git merge-base <branch1> <branch2>

运行该命令我发现合并库是4f87376b5

距离您上次将 master 合并到您的分支已经不到 5 个月了。当您合并时，master 指向 2017-04-24 的提交。（现在是您当前合并的合并基础。）

自那时以来，主分支上已提交 123 次，最近一次提交是在 2017 年 9 月 19 日。这 123 次提交可能与您分支上无法从 master 访问的 137 次提交中的任何更改发生冲突。

Git 不会查看“提交次数”或它们发生的时间和地点。它所看到的只是每个分支头和合并基础之间的累积差异。您可以运行 git diff 4f87376b5 ohcibi 和 git diff 4f87376b5 origin/master 来查看从合并的每一侧集成的更改范围。

【讨论】：

好吧，问题有点复杂，可以通过简单的严格提取和合并来避免，无论如何我一直在做 8-)。 4f8737 仍然没有真正显示问题，但 git show-branch 确实列出了所有分歧的提交，这是自 ohcibi 中的第一个提交以来的每个提交。 ohcibi 应该不包含在 master 中，但 master 应该不时合并到 ohcibi 中，这似乎不像我预期的那样工作。
@ohcibi 我第一次看的时候看错了日期，以为是八月而不是四月。所以这不是一个过时的问题（我已经更新了我的答案）它只是在那个时期发生了很多变化的情况。
这也与很多更改无关。我找到了一个解释：父存储库一直在移动。它在另一个地方出现分歧，因为最初的维护者似乎迷路了。最终他回来并决定不合并来自临时上游的更改。当我移回原始上游时，我决定将这些更改重新定位到我的ohcibi 分支，因为临时不会继续。现在，每当上游添加的更改与临时上游所做的更改发生冲突时，我就注定会遇到这些合并冲突。
@ohcibi 这很有道理，但它会让你回到同一个地方，你的分支中有很多与主分支冲突的更改。顺便说一句，如果您已经根据项目维护者拒绝的更改构建了分支，那么您最好从更新的记录源构建一个新分支。如果您的分支被接受，这将解决您的问题并避免将被拒绝的代码集成到 master 中的任何问题。
不，它不会让我回到同一个地方，因为我对此无能为力。 ohcibi 分支中的提交永远不会在 master 分支中，因此永远冲突。 ohcibi 分支从未打算包含这些文件中的更改。但是当我将临时上游的更改重新设置为ohcibi 时，情况不再如此。我最初对这个设置的想法被打破了，因为我在做的时候没有想到我的 rebase。我只需要想一些新的东西，但这是另一个问题。