Git Merge覆盖本地分支文件而不发出合并冲突信号

我今天遇到了一个情况，Git merge不能对一个文件正常工作。这就是我所做的：

我在当地有一家分公司，我在那里工作

然后branch大师被其他人的作品更新了

我先执行git主签出，然后执行git pull（将所有这些更改拉入本地主分支）

然后我切换回我的本地分支，并执行git pull origin master将所有主分支更改拉入我的本地分支

在这15个文件中，有几个是合并冲突。但有一个主分支和本地分支之间存在合并冲突差异的文件未注册为合并冲突。Git刚刚用master branch的最新版本重写了我的本地分支版本的文件

---

我是否做错了什么，或者这是git中的一个bug？

编辑-下面的两个可能的解释写得好像讨论中的合并是从您的分支到主分支；我不知道我是怎么想出来的，但我正在更新它们，以反映您正在从master合并到您的分支

---

正如评论中所指出的，我们确实需要更多的信息来明确说明发生了什么。我会尽力关注这一点，如果我们得到更多细节，我会更新一个更好的答案，但现在我想说有几个可能的情况：

1） 根据diff算法，您的更改可能与主控更改没有冲突，因此该文件被静默替换为包含主控更改的副本。但如果是这样的话，那么该文件还包含对分支所做的更改。这将是一个正常的合并结果（不过，根据更改的不同，它们可能在逻辑上不一致，即使它们没有冲突——即没有修改文件的同一个“大块”）

如果您看到母版的一些更改，并断定它是母版，而不确定它没有您的更改，那么这是最有可能的情况。但是，如果您确实验证了您的更改不存在，那么这是另一回事

这很少出现问题，因为这通常是期望的行为；在设计良好的代码中，对同一文件进行逻辑上不一致的更改（但不会发生冲突）非常罕见

2） 提交图可能不是您所假设的。例如，在某个时刻，在您修改了一个文件之后，可能有人将您的分支合并为master。然后，他们可能以包括撤消更改在内的方式更改了该文件。他们的改变将取代你的

o - M -- D -- E <--(master)
 \ /           \
  A -- B -- C - M2 <--(branch)

---

o-M--D--E根据你在问题中所说的，你所描述的合并冲突实际上不是合并冲突，你需要展示而不是描述问题（并且以读者清楚或可复制的方式）
或者这是git中的一个bug？
不太可能。问题是：git不同意您的意见，并且认为它做了正确的事情。也就是说，它接受的版本很可能被标记为合法版本或更改。这种情况有时会发生，修复它只意味着在与另一个分支合并后需要区分该文件并手动修补它。@TimBiegeleisen这太痛苦了！但是git的全部要点是，它应该轻松地处理这个问题——分布式团队在相同的代码库（甚至是相同的文件）上工作，Tim说的不是真的。如果git认为主版本合法地覆盖了您的，但您没有，那么有一个具体的原因是可以理解的；这不是“碰巧发生”的事情。多人同时工作——包括在同一个文件上——正是git设计的目的；没有“好的通用工作流模式”可以避免这种情况。有很多源代码管理工具需要这种行为，而且它们并不流行。