用于跟踪Mercurial中的上游存储库的工作流程

Question

我不确定什么是我想要完成的最好的Mercurial工作流程，所以我正在寻找任何提示和想法。

主要开发发生在主仓库上，而且我有许多客户特定的回购与主人几乎相同，只有很少的调整在这里和那里特定于该客户的需求。

我当前的工作流程是在主仓库中有一个命名分支（名称： webapp ），然后为每个客户克隆该仓库。每个客户仓库都有一个命名分支（名称：客户＃），然后我定期从主仓库中提取，合并两个分支（ webapp 和客户＃< / em>）并整理冲突。

这是我正在尝试做的最好的工作流程，还是有更好的方法来跟踪每个克隆添加小调整的上游回购？

Answer 1

这是教科书案例，其中功能分支（这是你有效的做法）是一个糟糕的选择。相反，请考虑branching by abstraction，它在DVCS意义上不分支，而是代码中的分支。

Answer 2

不是“更好”|“更糟糕”，但略有不同的方式可能是使用MQ（和没有分支的单主线）和mq-patches用于客户特定的更改而不是不同存储库中的分支。

在极端情况下，它可以是永久更改集中具有核心的单个存储库，并且如果将MQ-queues（每个客户的队列）和pull | merge | resolve替换为pull | apply path | resolve | save edited patch

Answer 3

据我所知，没有比现有方法更简单或更简单的方法。

真正的困难是不分支/工作流策略的问题，但是整体代码结构存在问题：我的意思是主要和自定义分支（或版本）之间存在潜在的冲突。通过选择“更好”的分支/工作流程策略，此问题不会自动消失。因为它本质上是一个代码问题，你必须在代码级别解决它，或者通过在将main与自定义分支合并的过程中手动解决冲突，或者通过隔离各种自定义来解决冲突。主要代码使后者的任何变化都不会影响前者。无论哪种方式显然都有其优点和缺点。如果经常发生合并和冲突，你会考虑采用第二种方式;否则，你目前的做法就是IMO。