什么是反向合并

Question

我在git-flow脚本上观看了一些视频,其中一个术语是"后合并" - 例如,将修补程序合并到master中,然后将其合并到develop中.

我假设返回merge是一个概念而不是本机git命令.什么确切的命令包含后合并操作？

Answer 1

术语"反向合并"的使用通常有些武断.

它只是意味着像其他任何一样进行合并,但是在与分支约定的正常流程相比"向后"的方向上.如果你可视化分支排列的像

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

然后通常从右到左改变"流动" - 特征到开发释放到主人.但是,虽然修补程序相当遥远 - 它们是从master创建的 - 它们仍然必须"合并"到右侧dev,因此有些人将其描述为向后合并或反向合并.

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

这个术语更引人注目的用法是当你有一个长期存在的特征分支(它本身就是敏捷过程中的反模式,可能使用gitflow;但有时你可能需要一个).在这种情况下,您应定期更新dev中的长期功能,以便两者不会过多地偏离,从而导致合并冲突的灾难.(这开辟了一大堆关于"不必要的"合并的蠕虫,是什么造就了一段美好的历史,而且git rerere......我离题了.) 这显然可以被称为后合并,因为相反 - 将你的特征合并到开发中 - 是分支模型中合并的正常教科书.

Answer 2

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

假设您有两个分支Develop和Master
您在Master上发现了任何重大错误。您将其作为修补程序固定在 Master 分支本身上。稍后您需要将您的错误修复更改添加到您当前的工作分支，即开发分支。所以你需要像这样进行反向合并

1. git checkout 开发
2. git合并大师
3. git push origin 开发

Answer 3

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

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

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