TL; DR ：从纯粹的理论角度来看，Git是否有可能在分支的合并（而非重新定位）期间报告文件冲突为主如果该分支上的文件从未被修改过（直接从master创建）？
当我将我的dev分支合并回master时，我经常会遇到文件冲突，这些文件在我的生活中我记不起来曾经修改过 - 甚至打开过。因此，我试图理解 - 鉴于Git是如何工作的，我不太了解 - 这在具体情况下实际上是可能的，或者如果这是不可能的，那么我应该专注于显然修改我的一些文件的东西工作树，没有我注意到（例如，像Eclipse中的Save Actions，自动格式化，行结束处理等）。
我只是谈论文件冲突，而不是树冲突，也没有其他可能涉及文件删除或重命名或移动的内容。
以下是我非常简单的典型工作流程示例，使用EGit和Eclipse（始终保持最新）：
1 ）我从master创建了一个dev分支;我勾选了＃34;配置上游推送和拉动＆＃34;复选框，并在＆＃34;拉动＆＃34;列表框我选择＆＃34;合并＆＃34; （其他条目是＆＃34; Rebase＆＃34;，＆＃34; Rebase保留合并提交＆＃34;，＆＃34; Rebase交互式＆＃34;）。
没有其他人会提交到该分支，本地和远程，，。只有我，只能从一台计算机上。
2 ）我检查了dev分支，有些日子我每天都会对其进行更改。每个提交都使用＆＃34; Commit and Push＆＃34;而不只是＆＃34;提交＆＃34;，因为我希望我的所有提交也始终在远程分支上。
在某些情况下，推送部分是我的＆＃34;提交和推送＆＃34;导致＆＃34;拒绝 - 不快进＆＃34;。在那些情况下做一个＆＃34; Pull＆＃34;然后重复推送解决方案，有些同事说，必须首先进行拉动才能避免Push导致＆＃34; Not fast-forward＆＃34;。但这不是问题。
3 ）是时候将我的dev分支合并回master了。我拉，切换回主人，拉，选择合并，选择我的本地开发分支，在＆＃34;合并选项＆＃34;我选择＆＃34;壁球＆＃34;，＆＃34;快进选项＆＃34;我保留默认＆＃34;如果是快进，只更新分支指针＆＃34; （其他选项是＆＃34;如果是快进，则创建合并提交＆＃34;＆＃34;如果不是快进，则失败＆＃34;）。
然后我点击Merge，我得到＆＃34;结果：冲突＆＃34;，我去解决这些冲突，在某些情况下，冲突的代码都没有显示为红色＆＃34; Mine＆＃34; （主人）也没有相应的代码，红色显示在＆＃34;他们的＆＃34; （我的开发部门）是我写的东西。我从来没有在任何部分修改过该文件，但在将此文件从未更改过的分支合并到master中时，它仍然存在冲突的变化。
所以我的问题是，从纯粹的理论角度来看，是否存在Git应该在将分支合并到主服务器期间报告文件冲突的情况，尽管该文件在分支上根本没有被修改过？如果是，我上面描述的工作流程是否属于这种情况之一？
它不是this的副本，因为它是关于使用rebase的。
答案 0 :(得分：1)
更新 - 意识到我忘了回去直接回答这个问题......
首先要做的事情：如果你必须在你可以推动之前拉，那么其他人正在你修改并正在推动的分支上提交。按照你的描述，我不能100％确定 - 我需要知道具体的命令和配置设置 - 但我敢打赌，这意味着你错了，没有其他人承诺你的分支。
我之所以提到这是因为你问git理论上是否可以做某事，因为你的观察结果说它可能正在发生......但那些观察结果不是自我一致的，所以不能完全正确。
当分支没有变化时，是否会发生合并？
不在您描述的条件下。 ......好吧，好吧，你说“理论上”，所以我会批准如果你出于某种原因使用一个被编码为恶意的替代合并工具，我无法证明这个是不可能的。但鉴于我的上述评论，我会说我不相信这就是这里发生的事情。
说你有
R -- x1 ... xN -- A <--(master)
\
o1 ... oN -- B <--(branch)
您即将branch合并到master。如果文件foo存在冲突，则根据定义，这意味着
（A）在p1和foo之间的x1处应用了更改A，
（B）在p2和foo之间某处o1应用了更改B，
（C）p1和p2被视为“重叠”
现在，p2可能有很多方法可以隐藏在图表中的...后面。例如，可能有人从branch2创建branch，进行了一些更改，并将branch2合并回branch。但是合并回branch 仍然仍然是“其他人在该场景中提交对branch的更改（并且合并提交的外观将是您何时的示例”）在你推动之前必须先拉。）
那么如何分辨出真正发生的事情呢？
如果git报告了冲突，你可以通过查看冲突标记来了解它的想法。如果这只是一个你不记得的变化问题，也许它们看起来很熟悉？但听起来并非如此。
（以下命令假定合并仍未完成;如果合并已提交，那么您将使用类似master^..branch的内容;该点是..必须引用之前的部分合并前master提交。）
所以你可以看到哪些提交影响了文件（但不在master中），如
git log master..branch -- path/to/conflicted/file
如果不能清除它，另一步就是尝试
git blame master..branch -- path/to/conflicted/file
（如果需要，您可以在-L一侧的branch一侧列出git blame个选项，以参见apply plugin: 'idea'
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'maven-publish'
sourceCompatibility = 1.8
version = '1.0'
sourceSets {
jars
}
repositories {
jcenter()
mavenCentral()
}
dependencies {
compile fileTree(dir: "src/jars/resources", include: ['*.jar'])
compile group: 'org.testng', name: 'testng', version: '6.9.10'
compile group: 'org.seleniumhq.selenium', name: 'selenium-java', version: '3.+'
compile group: 'io.appium', name: 'java-client', version: '4.1.2'
compile 'com.testdroid:testdroid-api:2.9'
compile group: 'org.json', name: 'json', version: '20141113'
}
compileJava {
options.encoding = "UTF-8"
}
test {
useTestNG {
suites 'src/main/resources/testng.xml'
}
}
文档。
这应该告诉你谁，何时以及在什么时候提交。