git - 什么是反向 merge

Question

我看过一些关于 git-flow 脚本的视频，其中一个术语是“反向 merge ”——例如hotfix merge 到 master 中，然后 merge 到 develop 中。

我假设反向 merge 是一个概念而不是本地 git 命令。哪些确切的命令构成反向 merge 操作？

Answer 1

术语“反向 merge ”的使用通常有些武断。

它只是意味着像其他任何操作一样进行 merge ，但是与分支约定的正常流程相比，它的方向是“向后”的。如果您将分支想象成这样排列

master    hotfix    release    dev    feature
  |          |         |        |         |
  |          |         |        |         |
  |          |         |        |         |
  |          |         |        |         |

然后通常从右到左“流动”- 特性到开发到发布到主控。但是，尽管修补程序非常靠左 - 它们是从 master 创建的 - 它们仍然必须“向右” merge 到 dev 中，因此有些人将其描述为向后 merge 或向后 merge 。

在我看来，这不是该术语最引人注目的用法，因为它可以被理解为暗示相反的 merge (从开发到修补程序分支)是“前向 merge ”——但实际上这应该是完成。在这种情况下，如果您以上述特定方式可视化分支，那么“向后”的方向更多地是关于变化的一般流程。

这个术语更有说服力的用法是当你有一个长期存在的特性分支时(它本身是可能使用 gitflow 的敏捷流程中的一种反模式；但有时你可能需要一个)。在这种情况下，您应该定期从开发人员更新长期存在的功能，这样两者就不会偏离太多导致以后发生 merge 冲突的灾难。 (这打开了一大堆关于“不必要的” merge 的蠕虫，什么是好的历史，以及 git rerere...但我离题了。)那可以清楚地被称为反向 merge ，因为相反 - 将您的功能 merge 到开发中 - 是分支模型中 merge 的正常教科书使用。