Git 通过合并提交还原更改，然后重新合并

我在X分公司工作，从Y分公司接收货物，由其他开发人员负责维护。 我将Y合并到X中，但需要将Y中某些错误提交的更改恢复到文件“KKK”中，并在修复其他更改的同时继续处理这些更改。这会导致我在分支X中对文件“KKK”[我通常从未接触过]进行还原提交。这意味着在分支Y中继续对其进行操作时，我的分支中的“KKK”会还原为“版本a”（见图）

接下来，当“KKK”在“Version I”中变得更成熟时，我将Y合并到X中，这次希望“KKK”更新为“Version I”。相反，git在进行合并时会自动接受我的revert提交'Version A'并忽略'Version I'。该文件仍处于“版本A”。为什么会发生这种情况？我的工作方式有问题吗

我有一种感觉，这在某种程度上与“快进合并”有关，但我不确定

---

提前感谢。

当你还原某件东西时，它的意思是“我永远都不想要这个改变”（因为它坏了）

合并分支时，Git（或任何DVC）只合并来自新提交的新更改。您还原的更改已经合并，因此不会重新合并（否则，整个还原点将是徒劳的–SCM如何知道哪些还原是真正的还原，哪些不是？）

视觉上：

A-B-M-C'--X-... <- branch a
   /     /
C-D-----E--..   <- branch b

---

A-B-M-C'--X-。。。谢谢你的回复。在您绘制的提交树中，每个提交更改都是对同一个文件的吗？@AnshGandhi这一事实与还原的工作方式是正交的。但是，是的，如果恢复仅涉及单个文件的提交，则所有其他提交/更改仍将“正常”显示。但这对本次讨论来说并不重要。我将尝试重新表述-@knittl假设这些提交都是对同一个文件的，为什么git没有显示文件的C'版本和E版本之间的冲突，说明文件在两个分支中都已完成了工作？@AnshGandhi一种可能是对文件的不同部分进行了更改。例如，提交
C
更改了第21行，提交
C'
还原了第21行，提交
E
更改了第42行。所有文件都接触同一个文件，但不会有内容冲突。如果它们确实接触到相同的线，那么您应该会遇到冲突。你有MWE吗？对不起，收音机的声音太小了，我已经走了。我和我的另一位同事讨论过这个问题，他说“git看的不是文件而是内容。”这让我更清楚了。。。所以X版实际上是C'和E的内容更改的合并，在这种情况下，对吗？如果是这样的话，那么您关于恢复的建议也是有意义的。对不起，我没有“mwe”。刚刚知道那是什么。奇怪的问题-对于那些无法读取git代码的文件，它应该在合并E时引发冲突，对吗@针织品