Git 合并热修复程序分支以进行开发重新引入了旧的更改

我们一直在我们的团队中尝试git flow。我们在开发分支的基础上创建发布分支。然后合并发布分支，在发布后进行开发和掌握。到目前为止，我们已经发布了几个没有修补程序的版本

现在，我们刚刚发生了一个需要热修复程序的事件。因此，我们基于master创建了修补程序分支。我们将修补程序分支合并到master，一切都很好。然后我们尝试合并热修复程序分支进行开发，diff显示旧的更改被重新引入到开发中。例如，有些文件本应删除，但在合并后重新添加到develop中。在合并之前，staging和master都是相同的，没有任何区别

你知道这是什么原因吗？我想显示示例历史/图表，但由于合并，我们的历史非常混乱

你知道这是什么原因吗

当然，可以选择合并基提交。这个选择不是你的：Git根据提交图自动进行选择。这就是为什么这一步：

因此，我们创建了基于master的修补程序分支

如果您愿意的话，可能是创建错误或根本原因

您可以使用以下工具查看Git认为哪些提交是develop和master的合并基础：

这将打印出一个或多个提交哈希ID。1如果只打印一个哈希ID（通常情况下），则该哈希ID是合并基提交的哈希ID。如果它打印两个或更多，Git将通过合并列出的提交为Git merge recursive构建一个合并基础；这些情况很棘手

请记住，git merge是关于组合更改的，但git根本不存储更改。Git存储快照：每次提交都会保存每个文件的完整快照，作为一种时间冻结归档，表示项目在这个快照时间是这样的。将快照转换为更改的唯一方法是至少拍摄两个快照并对其进行比较，就像玩一场游戏一样

找出两个分支提示master和develop之间的差异是没有用的，因为将这些差异应用于其中一个分支提示只会生成另一个快照。在这种情况下，我们为什么还要为树枝而烦恼呢？所以这不是合并的工作方式

相反，merge会在master和development发散之前找到过去某个地方的快照。通过将该快照与master末尾的快照进行比较，Git可以看到master中发生了什么变化。通过将相同的快照与开发结束时的快照进行比较，Git可以看到开发中发生了什么变化。然后，Git可以组合这两组更改，以便保留您的更改，但也可以添加它们的更改

这个过程很简单，虽然在实践中做了很多工作，但在算法上相对简单，这就是为什么我们让计算机来做这件事。在某些情况下，它太简单，并产生错误的结果。你的案子似乎就是其中之一

如果您发现在过去某个时候（可能是遥远的过去）引入了错误本身的提交，并在引入错误后立即修复该错误，那么您可以将该分支合并到master和developer中。从这个分支的合并基础（master或development）到这个分支的tip的更改将只是修复。从这个合并库到master或develope的tip的更改将是发生的所有其他更改。因此，将这个分支合并到master和develop中通常会产生正确的结果，而不会引入其他不必要的更改。但这通常更困难，有时甚至比为master创建一个热修复分支困难得多。所以选择权在你

<>你可以考虑使用Git Cyt Poice作为一个方法，将修复程序复制到开发分支。樱桃采摘有它自己的危害，例如，如果热修复程序被证明有它自己的错误，现在你需要修复它两次，但这是商店里的另一个工具。Git是一家有很多工具的大商店。选择正确的锯子、锉刀、锤子、刨子、螺丝刀、钻头等等，你会做很多好事。选错一个，然后。。。嗯

---

1如果历史记录不相关，它可能根本不打印，但在这种情况下，您可能会看到有关不相关历史记录的错误。

更新：当我执行git diff develop master时，发现develop和master之间存在差异。同样，当我在Gitlab中比较分支master->develope时，它显示了差异，但是当比较develope->master时，没有差异。非常奇怪。

git merge-base --all develop master