什么是回购 [英] What is a back-merge

问题描述

我看了一些有关git-flow脚本的视频，其中一个词是反向合并"，例如修补程序被合并到母版中，然后又被合并到开发中.

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命令.什么确切的命令构成反向合并操作?

I’m assuming back merge is a concept and not a native git command. What exact commands comprise a back merge operation?

推荐答案

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

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
  |          |         |        |         |
  |          |         |        |         |
  |          |         |        |         |
  |          |         |        |         |

然后通常将流程"从右向左更改-开发人员将其功能发布到母版.但是，尽管修补程序的位置最左端(它们是从母版创建的)，但仍必须向右"合并到dev中，因此有些人将其描述为向后合并或向后合并.

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.

在我看来，这并不是该术语最引人注目的用法，因为它可以理解为暗示相反的合并(从dev到hotfix分支)是向前合并"-但实际上，这应该避免没有做.在这种情况下，如果以上述特定方式可视化分支，则向后"的方向更多地是关于变更的一般流程.

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.

该术语的一种更引人注目的用法是当您拥有一个长期存在的功能分支时(该分支本身是可能使用gitflow的敏捷流程中的一种反模式；但有时您可能需要一个).在这种情况下，您应该定期从dev更新您的长期功能，以免两者之间的偏差太大，从而导致以后发生合并冲突. (这打开了一堆蠕虫，它们涉及不必要的"合并，产生良好历史的内容以及git rerere ...但我离题了.) 可以明确地称为反向合并因为相反的做法是将教科书中的功能合并到开发人员中，这是分支模型中正常使用的教科书.

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.) That can 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.

这篇关于什么是回购的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！