我们有一个通用的开发分支，其中包含所有经过 QA 测试的功能。我们让一位同事完成了他们的功能，QA将其合并到开发中。
这不仅删除了大量文件，而且当我尝试将 development 合并回我的分支(以解决任何冲突)时，它会覆盖我的更改(较新)以支持开发(较旧)。
什么可能导致这种情况发生？似乎这是一个孤立的事件，但我们希望确保它不会再次发生。这几乎就像文件上的"修改"时间在开发时是较新的，这是不可能的。
首先："修改时间"与合并结果的计算方式无关。 事实上，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的使用方式，仔细检查，可以解释发生了什么;在这种情况下，与其挖掘历史，不如确保每个人都理解使用该命令的细微差别。