Mercurial:如何使用两个“主要分支”

时间:2017-09-22 09:09:52

标签: mercurial branching-and-merging

我有一个项目的Mercurial存储库,必须拆分为两个将共享主要功能的分支,但它们的某些功能会有所不同:

            ---- B
           /
---source-+----- A

现在我想知道我是如何使用它的。

                          ----- new feature -------
                         /                         \
            ---- B1 ----+ B2 --- B3 ----- bugfix ---+- MERGE ---
           /
---source-+----- A1 ---- A2 ------------------------------------

假设A1,B1,B2,......等是简单的更改,只应出现在特定的分支中(更新徽标,更改文本,...)。但是我想在两个分支中同时拥有“新功能”和“错误修正”。

显然我不能将分支B合并到A中,或者我最终会得到我在A中B中所做的所有更改(但我不想要更新的徽标)。

所以:我该怎么做?我是否真的必须使用this question中建议的第三个分支?这将迫使我适应一个全新的工作流程。

另一个related question建议移植和移植。这是要走的路吗?

1 个答案:

答案 0 :(得分:2)

你勾勒出来的两种方式中的任何一种都很好 - 这更像是你最喜欢的事情:

a)有三个分支,一个主线,每个项目/客户都需要一切 - 以及两个客户分支,相对于主线更改徽标或文本的具体变化。 Mainline接收错误修复和新功能,并定期合并到客户分支中。这样他们就不会“污染”彼此。

b)将其保留在两个分支机构,每个客户一个分支机构,并将与两者相关的更改移植到另一个分支机构。

选择a)或b)是一个品味问题,在我看来更多的问题是你是否会有更多的变更集由两者共享(然后是3个分支,更少的嫁接),或者你是否有更多的变更集特定于一个分支或另一个分支 - 然后嫁接工作较少。可能我几乎总是选择a);感觉“更干净”。

实际上有一个选项c):将两个分支合并到另一个分支中并在合并时注意不要合并特定于另一个分支的东西。但这可能非常乏味,至少从长远来看;这主要取决于差异的复杂程度以及它们在一般变化方面的位置。如果细节在他们自己的文件中,合并和跳过合并期间的“错误”更改相对容易。