问什么是反向合并

EN

术语"back merge“的使用通常有点随意。

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

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

然后正常地将“流”从右到左-从功能到开发再到发布到主控。但是，尽管修补程序非常靠左-它们是从master创建的-它们仍然必须“向右”合并到dev中，所以有些人将其描述为向后合并，或向后合并。

在我看来，这并不是这个术语最令人信服的用法，因为它可以被解读为暗示相反的合并(从dev到hotfix分支)是“正向合并”-但实际上这是不应该做的事情。在这种情况下，“向后”的方向更多地是关于变更的一般流程，如果您以上述特定方式可视化分支的话。

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

Backmerge只不过是将您的修补程序更改添加到当前工作分支中。

假设您有两个分支Develop和Master

您在Master上发现了任何重大错误。您在主分支上将其修复为热修复。稍后，您需要将错误修复更改添加到您的当前工作分支中，即开发分支。因此，您需要像这样反向合并

1. git签出开发
2. git merge主
3. git推送原点开发

它只是两个普通的merge命令：

git checkout master
git merge hotfix
git checkout develop
git merge hotfix

当工作完成时，您可以认为提交的“正常”流是从您的开发分支到master。在反向合并中，提交以相反的方向流动，从hotfix流向您的开发分支。