我们有一个共同的开发分支，其中包含所有经过QA测试的功能。我们让一位同事完成了他们的功能，QA将其合并到了开发中。
这不仅删除了大量文件，而且当我尝试将开发合并到我的分支（以解决任何冲突）时，它会覆盖我的更改（更新）以支持开发（更旧）。
可能导致这种情况发生的原因是什么？似乎这是一个孤立的事件，但我们想确保它不会再发生。这几乎就好像文件上的“修改”时间在开发时更新，这是不可能的。
答案 0 :(得分：0)
首先要做的事情是：“修改时间”与合并结果的计算方式无关。实际上，git不会优先考虑更新的更改，也不会优先考虑更新的更改或任何类似的更改。变化是一种变化。
在合并期间，git找到一个“合并基础”（最近一次提交，它是合并中涉及的两个（或所有）提交的祖先），计算出自合并基础以来所做的所有更改（两者都在（全部） ）分支），并弄清楚如果将所有这些更改应用于合并库，会发生什么。唯一需要“更喜欢”一个更改而另一个更改的是两个分支修改了相同的代码块，在这种情况下，默认行为是报告合并冲突。
然而，您发现旧版本的代码会覆盖新版本的代码，为什么呢？
我认为最可能的原因是没有在某个地方占用git revert。这并不是说revert是坏的;通常这是最好用的。但在某些情况下，如果你不了解它们，它会产生混淆的后果。
特别是如果有人还原了合并提交，它往往导致这种事情;或分支，然后从分支点之前恢复提交。
当然这是猜测（如果我试图在不知道更多的情况下推荐修复，那将是危险的推测）。它可能是不同的东西。要知道，人们必须分析你的历史。如果您要将feature与develop合并，则可以先说
git merge-base feature develop
将告诉您用于合并库的提交的ID。然后，您可以使用git diff <id> feature和git diff <id> develop来查看git在合并期间看到的内容。或者用git log -p <id>..feature等跟踪变化的演变。
但话又说回来，或许可以四处询问，revert的使用方式经过仔细检查，解释了发生的事情;在这种情况下，您可以反而只是确保每个人都了解使用该命令的细微差别，而不是挖掘历史。