我观看了一些关于git-flow脚本的视频，其中出现了一个术语“回溯合并”-例如，hotfix分支合并到了master分支，并回溯合并到develop分支。
我猜测回溯合并是一个概念，而不是原生的git命令。那么回溯合并操作包括哪些确切的命令？
3个回答
46
“反向合并(back merge)”这个术语的使用通常有些武断。
它仅仅意味着进行一个合并，就像其他任何合并一样，但是在与分支约定的正常流程相反的方向上进行。如果你将分支可视化排列，就像：
master hotfix release dev feature
| | | | |
| | | | |
| | | | |
| | | | |
通常情况下，更改会从右向左“流动” - 从特性分支到开发分支再到发布分支最终合并到主分支。但是，虽然热修复分支位于整个流程的极左侧 - 它们是从主分支创建的，但它们仍然必须“向右”合并到dev，因此有些人将其描述为向后合并或回溯合并。
我认为这不是该术语最具说服力的用法，因为它可能被解释为相反的合并（从dev到热修复分支）是一种“向前合并”，但实际上这是不应该做的事情。在这种情况下，“向后”的方向更多地涉及到如果您按照以上特定方式可视化分支的更改总体流程。
更具说服力的用法是当您拥有一个长期存在的特性分支（它本身就是敏捷过程中可能使用gitflow的反模式之一;但有时您可能需要一个）。在这种情况下，您应该定期将您的长期特性与dev更新，以便两者不会偏离太多，从而导致稍后的合并冲突灾难。（这引发了关于“不必要”合并，什么才是好的历史以及git rerere等问题，但我离题了。）可以明显地称之为回溯合并，因为相反的行为-将您的特性合并到dev中-是分支模型中合并的正常且经典用法。
- Mark Adelsberger
30
Backmerge指的是将热修复更改添加到当前工作分支中。
假设你有两个分支Develop和Master。
在Master上发现一个重要的错误，你在Master分支上进行了修复。hotfix之后，你需要将修复补丁合并到当前的工作分支即Develop分支。这时需要执行以下back-merge操作：
- git checkout Develop
- git merge Master
- git push origin Develop
- Vrushali Raut
1
是的，所以我们只需创建一个像这样的PR：[base: Develop <--- compare: MASTER]。通常情况下，您会在Develop分支中开发和实现代码更改，并将它们推送到Master分支。但在这种特殊情况下，“热修复”通常是一种破坏性/阻塞/关键代码更改，可以挽救我们的一天。在这种情况下，时间是至关重要的约束条件。因此，您不能从Devlop-> Test-> Stage-> Master，而是直接在Master上进行代码更改，然后进行回溯合并，以便其他分支知道其后继者的代码更改。 - Aniket
9
这只是两个普通的合并命令:
git checkout master
git merge hotfix
git checkout develop
git merge hotfix
你可以将提交的“正常”流程视为从你的开发分支到
master，因为工作已经完成。在回溯合并中，提交是以相反的方向流动的，从hotfix进入你的开发分支。- chepner
3
2通常最后一个命令实际上应该是
git merge master（你正在将主分支“回合并”到开发分支中）。正如其他人指出的那样，这是一个不精确的术语，但我见过它被使用的方式。 - mgalgs这个对我来说最有意义，但是将
git merge hotfix 替换为 git merge release，以将一个发布分支与 Develop 分支合并。 - Christopher Carswell前两个命令
git checkout master 和 git merge hotfix 是正常流程。 （将某些内容发送到生产环境）
最后两个命令 git checkout develop 和 git merge hotfix 是回退合并流程。 （从hotfix中获取某些内容） - Rohit Kumar Shrivastava网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接