Git 什么是反向合并

我看过一些关于git流脚本的视频，其中一个术语是“反向合并”——例如，修补程序合并到master中，反向合并到develop中

---

我假设backmerge是一个概念，而不是一个本地git命令。什么确切的命令构成了反向合并操作？

它只是两个普通的合并命令：

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

当工作完成时，您可以将提交的“正常”流程想象为从您的开发分支到

master

。在后向合并中，提交是以相反的方向流动的，从

修补程序

进入开发分支。

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

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

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

然后从右到左正常地改变“流”——特性到dev再到master。但是，虽然热修复程序非常左-它们是从主程序创建的-它们仍然必须“向右”合并到

dev

，所以有些人将其描述为向后合并，或向后合并

在我看来，这并不是这个术语最引人注目的用法，因为它可以被理解为暗示相反的合并（从dev到hotfix分支）是“正向合并”——但事实上这是不应该做的事情。在这种情况下，如果您以上述特定方式可视化分支，则“向后”的方向更多地是关于一般的更改流

---

这个术语的一个更引人注目的用法是当您拥有一个长期存在的特性分支时（这本身在敏捷过程中是一种反模式，可能会使用gitflow；但有时您可能需要一个）。在这种情况下，您应该定期从dev更新您的长期特性，这样两者就不会偏离太多，导致以后的合并冲突灾难。（这打开了一整罐关于“不必要的”合并的蠕虫，是什么造就了一个好的历史，还有

git rere

…但我离题了。）这显然可以称为反向合并，因为相反的情况——将您的功能合并到dev中——是正常的，在分支模型中使用合并的教科书。

反向合并只不过是将修补程序更改添加到当前工作分支。

假设您有两个分支开发和掌握
您在主机上发现任何主要错误。 您已将其作为一个修补程序固定在主分支上。 稍后，您需要将错误修复更改添加到当前工作分支，即开发分支。 因此，您需要像这样执行反向合并

---

git签出开发

git合并主机

git推源开发

---

通常，最后一个命令实际上是

git merge master

（您正在将master“向后合并”到develope中）。正如其他人所指出的，这是一个不精确的术语，但我看到它的使用方式。这一术语对我来说最有意义，但不是

git merge hotfix

，而是用

git merge release

替换，将发布分支与开发分支合并。关于这个主题，有一点可能帮助人们理解为什么要进行“反向合并”在热修复后需要。