2

我正在努力寻找一种使用 Mercurial 处理我的工作流程的好方法。我在 SO 和其他地方阅读了许多相关问题，但找不到合理的解决方案。

假设我有两个分支：

  1. 我在其中进行正常开发的默认分支。从中部署发布并使用发布标签对其进行标记
  2. 单独维护的特定客户的分支机构。它在一个单独的版本号上运行，该版本号从应用程序的旧版本分支而来。

这两个分支现在大部分相同，但已经存在一些差异。随着时间的推移，他们会更加疏远。

这意味着我有 4 种类型的源文件：

  1. Type-A：在两个分支中保持相同的文件（如果引入了更改，则应该在两个分支中都存在）。这些是大部分文件。
  2. Type-B：只在默认分支中，不需要合并到客户分支中的文件
  3. Type-C：只在客户分支中的文件，不需要合并到默认分支中
  4. Type-D：两个分支中都存在的文件，具有共享代码，但也包含应该保持独立且特定于每个分支的代码

开发在默认分支上完成，并且有大部分是增量的定期版本。但我也有这两种情况：

  1. 对默认分支所做的一些更改也需要合并到客户分支（例如，需要修复/添加到两者的错误或功能）。
  2. 对客户分支完成的“修补程序”，不能立即合并到默认分支，但最终需要在某个时候合并。

问题是我想不出一种相当简单、干净和安全的方法来支持这两种情况。Mercurial 没有部分合并或在合并时忽略文件的概念。它合并了变更集，但它坚持包含以前版本中引入的文件。

在这些场景中将 default 合并到 customer 分支或 customer 到 default 会迫使我添加 Type-B 和 Type-C 的文件。对不需要添加到另一个分支的 Type-A 文件进行更改（使其成为 Type-D）带来了挑战。

现在显然我可以通过使用编译器定义来解决其中一些问题（从而在两个分支中保持源文件相同），手动编辑代码并在合并后手动删除文件，但这并不是最有效和最干净的处理方式这。

当然，这是一个足够普遍的工作流程，比我更聪明的人已经想通了。任何人都可以提出任何可以简化这些场景中的工作的方法或最佳实践吗？还是我的设置存在根本缺陷？

另外，Git 是否更优雅地处理这些流程？

谢谢。

4

2 回答 2

3

我会在客户分支上进行客户需要的任何开发并将其合并到默认值中。这适用于修补程序，并且比从默认分支中挑选开发变更集更简单。向前合并比向后合并更容易。它还摆脱了 B 类文件问题，因为客户分支中没有 B 类文件。

我会合并到默认的 C 类文件，然后在默认分支上删除。对这些文件的任何进一步修改都应生成警告，指出在分支上修改的文件已在另一个分支上删除。

于 2012-11-14T22:08:53.150 回答
0

可以使用hg graft -r SRCREV命令在分支之间交换单独的变更集

更复杂且可能更难（但也更灵活和易于管理）的方式可能是使用 MQ 和多个队列（每个类型的队列？），但即使使用一个具有良好命名约定的 MQ 补丁队列，您也不会丢失

于 2012-11-14T14:22:48.413 回答