什么是反向合并

我看过一些关于 git-flow 脚本的视频，其中出现的一个术语是“反向合并”——例如hotfix 被合并到 master 中，然后又被合并到development 中。

我假设反向合并是一个概念，而不是原生 git 命令。向后合并操作包含哪些具体命令？

术语“反向合并”的使用通常有些随意。

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

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

然后通常将“流程”从右向左更改 - 从功能到开发，再到发布到主控。但是，虽然修补程序非常靠左 - 它们是从 master 创建的 - 它们仍然需要“向右”合并到dev，因此有些人将其描述为向后合并或反向合并。

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

该术语更引人注目的用法是当您拥有一个长期存在的功能分支时（这本身就是可能使用 gitflow 的敏捷流程中的一种反模式；但有时您可能需要一个）。在这种情况下，您应该定期从开发人员更新长期存在的功能，以便两者不会偏离太多，从而导致稍后合并冲突的灾难。 （这引发了一大堆关于“不必要的”合并的蠕虫，什么造就了良好的历史，以及git rerere...但我离题了。）That显然可以称为反向合并，因为相反的操作——将你的功能合并到开发中——是分支模型中合并的正常教科书用法。