Git — 合并然后还原，然后再次尝试合并

Question

Git 有时可能很神秘，那里的文档更是如此。 我和我的团队都面临着一个非常特殊的情况。 作为参考，我们有一个生产就绪的主分支和一个开发分支。 我们的分支策略如下：

• 分支 master 以创建功能分支
• 将功能合并到开发中以进行集成和功能测试
• 功能完成后向 master 提交合并请求

其中一位开发人员在将其合并到 master 之前不小心将 development 合并到了他的特性中，因此还有一堆未经审查的代码也进入了特性。 我将该合并恢复为 master，然后开发人员修复了他的分支以删除所有未经审查的代码。 然而，当试图再次将他的分支合并到 master 时，它抛出了一个错误。 这似乎是因为 master 已经有了功能分支的历史，所以它不会再接受它。

处理这种情况的正确方法是什么。

PS - 试图围绕合并和变基之间的区别。 我知道合并会引入代码更改并保留其他所有内容，从而为提交创建新的历史记录。 但是，rebase 是如何工作的？ 我的理解是，它将一个分支设置为与另一个分支完全相同的 state。 这个对吗？

Answer 1

Git 文档本身很好地解释了这一点，在revert a faulty merge下。 引用莱纳斯：

恢复常规提交只是有效地撤消了该提交所做的事情，而且相当简单。 但是恢复合并提交也会撤消提交更改的数据，但它对合并对历史的影响绝对没有任何作用。

所以合并仍然存在，它仍将被视为将两个分支连接在一起，未来的合并将把合并视为最后一个共享的 state - 恢复引入的合并的恢复根本不会影响它。

因此，“还原”撤消了数据更改，但它在某种意义上不是“撤消”，因为它不会撤消提交对存储库历史的影响。

因此，如果您将“还原”视为“撤消”，那么您将永远错过这部分还原。 是的，它会撤消数据，但不，它不会撤消历史记录。

有两个选项可以“再次”获取分支的更改：

1. 还原还原
2. 在没有错误代码的情况下重新设置分支，有效地创建新的历史记录，即全新的提交，然后合并这个新分支（它不会共享相同的历史记录，因此在合并时看起来“新”）