TL; DR：从纯理论的角度来看，是有可能的Git的合并过程中的一个文件报告冲突（不重订）的一个分支进入主如果该文件从未被所有修改的分支（它是直接从主创建的）？Git：在合并源中从未修改过的文件上是否会存在合并冲突？
当我将我的开发分支合并回主人时，我常常遇到文件上的冲突，这些文件对于我来说我不记得曾经修改 - 甚至打开过。所以我想了解是否 - 给定Git如何工作，哪些我不太了解 - 这在实际情况下可能是实际可行的，或者如果这是不可能的，那么我应该关注某些显然修改工作树中某些文件的内容没有我注意到（f.ex.类似Eclipse中的Save Actions，自动格式化，行尾处理等）。
我只是在谈论文件冲突，而不是树冲突，或者其他任何可能涉及文件删除或重新命名或移动的事情。
这是我的非常简单的典型的工作流程的例子，例如：It使用用Eclipse（始终是最新的）：
）创建从主一个Dev分支;我勾选了“为推拉配置上游”复选框，并在“拉取时”列表框中选择“合并”（其他条目为“重新部署”，“保留合并提交的重新保存”，“交互重新配置”）。
没有人会致力于该分支，本地和远程，在所有。只有我和只有一台电脑。
）我检查开发分支，并在几天内我每天都会对其进行更改。每一次提交都使用“提交和推送”而不是“提交”来完成，因为我希望我的所有提交都始终在远程分支上。
在某些情况下，我的“提交和推送”的推送部分导致“拒绝 - 不快进”。在这种情况下，执行“Pull”并重复推送解决方案，并且一些同事说，必须先执行Pull以避免Push导致“不快速前进”，这是正常的。但这不是问题。
）现在需要将我的开发分支合并回主。我拉，切换回主，拉，选择合并，选择我的本地开发分支，在“合并选项”下我选择“壁球”，在“快进选项”我离开默认“如果快进，只更新分支指针“（其他选项是”如果快进，创建合并提交“和”如果不是快进，失败“）。
然后我单击合并，然后得到“结果：冲突”，我去解决这些冲突，并且在某些情况下，既没有在“我的”（主）下显示为红色的冲突代码，也没有在“他们的“（我的开发部门）是我写的东西。我从来没有在任何部分修改过这个文件，但是当把这个文件从未改变过的分支合并到主文件中时，它的变化却发生了冲突。
所以我的问题是，从纯理论的角度来看，Git是否应该在分支合并到主文件时报告文件冲突，尽管该文件在分支上从未被修改过？如果是的话，我的工作流程是否符合上述情况之一？
这不是this的重复，因为这是关于使用rebase。
我们也遇到了无法解释的冲突，我认为我们在本例中对此进行了解释：有人对其他分支进行了提交。由于其他分支是该产品的旧版本（但仍然保留），因此这一提交与我们最新分支上的代码不兼容。然而，我们将旧分支合并到较新的分支以带来错误修正，因此从旧分支到我们当前分支完成虚拟合并，使用“我们的策略”忽略更改，然后重新实现。后来的合并在合并到其他分支时产生了冲突。 –
@ LasseV.Karlsen谢谢;我没有足够的技巧来判断这样的解释是否表明事实上完全可能，当我的分支合并到主分支中时，对于那些从未在该分支上修改过的文件产生冲突，但它确实听起来如此，更重要的是，让我意识到可能有其他团队成员可以做的事情 - 不是我的分支，而是主人 - 当我将分支合并到主人中时，最终会产生这些无法解释的冲突;我会试着去理解这种可能性是否真的存在，因为这可能是真正发生的事情。 – SantiBailors
当我们合并到主分支（您的案例中的主分支）时，我们特别使用'-s our'策略合并了“忽略来自其他分支的更改”。然而，当后来将这个分支合并到一个特性分支中以使其更新以修复我们**引入的合并冲突时，我们也收回了我们特别想要的那个其他分支的所有合并冲突忽视。最终，当这个策略合并之前我们没有创建更多的功能分支时，问题就消失了，但当它持续时，这是一个痛苦。 –