git 什么是反向合并
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/47555448/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is a back-merge
提问by mlhDev
I've watched some videos on the git-flow scripts and one term that comes up is “back merge” - e.g. hotfix is merged into master and back merged into develop.
我看过一些关于 git-flow 脚本的视频，出现的一个术语是“反向合并”——例如，修补程序被合并到主程序，然后再合并到开发程序。
I'm assuming back merge is a concept and not a native git command. What exact commands comprise a back merge operation?
我假设 back merge 是一个概念，而不是本机 git 命令。哪些确切的命令包含反向合并操作？
回答by Mark Adelsberger
The use of the term "back merge" is usually somewhat arbitrary.
术语“反向合并”的使用通常有点武断。
It just means to do a merge, like any other, but in a direction that is "backwards" compared to the normal flow of the branching conventions. If you visualize branches arranged like
它只是意味着进行合并，就像其他任何事情一样，但与分支约定的正常流程相比，是在“向后”的方向上进行的。如果你想象像这样排列的分支
master hotfix release dev feature
| | | | |
| | | | |
| | | | |
| | | | |
then changes normally "flow" from right to left - feature to dev to release to master. But while hotfixes are pretty far left - they get created from master - they still have to be merged "to the right" into dev, so some people describe that as merging backwards, or back-merging.
然后通常从右到左改变“流” - 功能到开发人员发布到主人。但是，尽管修补程序离我们很远——它们是从 master 创建的——它们仍然必须“向右”dev合并到 .
In my opinion, that's not the most compelling use of the term, because it can be read to imply that the opposite merge (from dev to a hotfix branch) were a "forward merge" - but in fact that's something that shouldn't be done. In this case the direction being "backward" is more about the general flow of changes if you visualize the branches in a particular way as above.
在我看来，这不是该术语最引人注目的用法，因为它可以被理解为暗示相反的合并（从开发到修补程序分支）是“向前合并” - 但实际上这是不应该的完毕。在这种情况下，如果您以上述特定方式可视化分支，则“向后”方向更多地是关于变化的一般流程。
A more compelling use of the term is when you have a long-lived feature branch (which itself is something of an anti-pattern in agile processes that are likely to use gitflow; but sometimes you may need one). In that case you periodically should update your long-lived feature from dev, so that the two don't deviate too much leading to a disaster of a merge conflict later. (And this opens up a whole can of worms about "unnecessary" merges, what makes a good history, and git rerere... but I digress.) Thatcan clearly be called a back-merge because the opposite - merging your feature in to dev - is a normal, textbook use of merge in the branch model.
该术语的一个更引人注目的用法是当您拥有一个长期存在的功能分支时（它本身是可能使用 gitflow 的敏捷流程中的一种反模式；但有时您可能需要一个）。在这种情况下，您应该定期从 dev 更新您的长期功能，这样两者就不会偏离太多导致以后发生合并冲突的灾难。（这打开了一整罐关于“不必要的”合并的蠕虫，什么是好的历史，而且git rerere......但我离题了。） 这显然可以称为反向合并，因为相反 - 将您的功能合并到开发中- 是分支模型中合并的正常教科书使用。
回答by Vrushali Raut
Backmerge is nothing but add your hotfix changes into your current working branch.
Backmerge 只不过是将您的修补程序更改添加到您当前的工作分支中。
Let's say you have two branches Developand Master
You found any major bug on Master.
You fixed it on Master branch itself as a hotfix.
Later you need to add your bugfix change into your current working branchi.e Develop branch.
so you need to do back-mergelike this
假设您有两个分支Develop和Master
您在Master上发现了任何重大错误。您将其作为修补程序固定在 Master 分支本身上。稍后您需要将您的错误修复更改添加到您当前的工作分支，即开发分支。所以你需要像这样进行反向合并
- git checkout Develop
- git merge Master
- git push origin Develop
- git checkout 开发
- git合并大师
- git push origin 开发
回答by chepner
It's just two ordinary merge commands:
这只是两个普通的合并命令：
git checkout master
git merge hotfix
git checkout develop
git merge hotfix
You can think of the "normal" flow of commits being from your development branch to masteras the work is completed. In a back-merge, the commits are flowing in the opposite direction, from hotfixintoyour development branch.
您可以认为提交的“正常”流程是从开发分支到master工作完成。在回合并时，提交的流向相反的方向，从hotfix入您的开发分支。
