对于我想要完成的工作，我不确定什么是最好的 Mercurial 工作流程，所以我正在寻找任何提示和想法。
主要开发发生在主存储库上，我有许多与主存储库几乎相同的客户特定存储库，只是针对该客户的需求进行了一些调整。
我当前的工作流程是在主存储库中创建一个命名分支（名称：webapp），然后为每个客户克隆该存储库。每个客户仓库都有一个命名分支（名称：customer#），然后我定期从主仓库拉取，合并两个分支（webapp 和 customer#) 并整理冲突。
对于我正在尝试做的事情，这是最好的工作流程，还是有更好的方法来跟踪上游存储库并为每个克隆添加小的调整？
【问题讨论】：
标签： version-control mercurial workflow
这是一个教科书案例，其中特征分支（这是您实际上正在做的事情）是一个糟糕的选择。相反，请考虑branching by abstraction，它不是 DVCS 意义上的分支，而是代码中的分支。
【讨论】：
不是“更好”|“更糟”，但稍有不同的方式可能是使用 MQ（以及没有分支的单个主线）和 mq-patches 进行客户特定的更改，而不是不同存储库中的分支。
在极端情况下，它可以是具有永久变更集中核心的单个存储库，并设置 MQ 队列（每个客户的队列）和 pull|merge|resolve 是否将替换为 pull|apply path|resolve|save 编辑的补丁
【讨论】：
据我所知，没有比您当前的方法更简单或更简单的方法了。
真正的困难不是分支/工作流策略的问题，而是你的整体代码结构的问题：我的意思是你在主分支和自定义分支（或版本）之间存在潜在的冲突。通过选择“更好的”分支/工作流策略，这个问题不会自动消失。因为它本质上是一个代码问题，所以您必须在 code 级别解决它，要么在将主分支合并到自定义分支的过程中手动解决冲突，要么将各种自定义项与主代码，以便后者的任何更改都不会影响前者。无论哪种方式显然都有其优点和缺点。如果合并和冲突非常频繁，可以考虑采用第二种方式；否则，您当前的方法就可以了 IMO。
【讨论】：