如何使用源代码控制管理同一项目的开源版本和商业版本？

Question

我们正在开发一个开源项目，我们使用 Mercurial 进行源代码管理控制。该项目的 Mercurial 存储库是公共的（我们使用的是 Bitbucket）。

现在我们有一个客户，我们需要为其定制我们的开源软件。这些定制必须保密，因此我们可能需要为此客户端创建一个新的 Hg 存储库；这个新的存储库将是私有的。

但问题是我们需要[不时]将开放存储库中的更改（例如新功能或错误修复）合并到我们的私有存储库中。

实现这一目标的最佳方法是什么？我读到可以合并两个或多个 Mercurial 存储库，但历史记录将会丢失。由于许多冲突，合并也可能会很痛苦。如果我们将来有更多的客户怎么办，我们应该如何管理他们的存储库？我们应该使用一个存储库和多个分支吗？如果两个项目版本开始走向不同的方向，并且两个存储库变得越来越不同怎么办？

请分享您对此的经验。

提前致谢！

Answer 1

您所描述的是分布式版本控制系统的标准事物：在两个存储库中进行开发并将一个存储库保留为另一个存储库的子集。首先为私有开发创建克隆：

hg clone open private

然后进入 private 并在那里创建新功能。照常提交。 私有存储库现在将包含比开放存储库更多的变更集——即新功能。

当错误修复和新功能作为正常开源流程的一部分放入 open 存储库时，您可以将它们拉入 private 存储库：

cd private
hg pull
hg merge

这样您就可以保持不变： 私有存储库始终包含开放版本中的所有内容，以及私有增强功能。如果您正在开发私有版本并发现错误，请记住查看开放版本以查看该错误是否也存在。如果是这样，那么先在开放版本中修复它，然后将错误修复合并到私有版本中。如果您错误地修复了私有版本中的错误，请使用hg移植将错误修复复制到其他开放版本。

历史不会有任何损失。当您执行 hg merge 时，您必须像平常一样解决合并，并且冲突只会与您的私人更改所需的大小相同。

要记住的重要一点是永远不要以其他方式推送（或拉动），除非您想开始将一些私有更改发布到开源版本中。

您可以对不同的客户端多次使用此设置，如果多个客户端需要相同的私有增强功能，您还可以根据需要在不同的私有存储库之间推送/拉取变更集。

Answer 2

原则上，基本模型相对简单；有一个单独的私有存储库，它是公共存储库的克隆（分支），在那里进行所有私有更改，然后定期将公共存储库合并到私有存储库中。历史保存方面没有问题，我不知道为什么你会读到这种情况。

然而，挑战在于不要最终陷入无法维护的合并地狱，而这只能通过严格的纪律来实现。

对于任何长期分支来说，最基本的经验法则是：

1. 使私有分支尽可能小。尽量减少其中的更改量，并保持较小的规模，这样就不要开始重构大部分代码或更改缩进。在像这里这样的单向合并情况下，您修改的任何代码都有可能发生冲突，甚至是直接发生冲突。

2. 经常合并。越频繁越好。如果您不这样做，那么每当您确实想要集成公共存储库中的更改时，您最终都会遇到一个存在大量冲突的超级合并。

此外，您还应该严格组织和编写代码以促进这种情况的发生。对于哪个分支上的内容以及代码片段的划分有明确的规则。

理想情况下，您可以将自定义功能建模为插件或外部库，甚至是一个单独的项目。这可能并不总是容易实现，在这种情况下，至少尝试根据使用工厂方法实例化的原始子类来编写所有私有修改。通过在仅存在于私有分支上的独立文件中进行所有更改，可以最大限度地降低冲突风险。

还编写自动化测试。很多。否则，您将无法立即检测到合并问题（这将会发生），并且私有分支通常会被破坏。

最后一个提示：在公共存储库上创建一个推送钩子，拒绝任何包含您知道是私有的变更集的推送；这将防止私人代码的意外发布，并可能为您省去很多麻烦。

Answer 3

嗯，一些扩展和变化。

• 对于 Martin 的工作流程，您可以使用“每个任务分支”范例（必须在基础项目中创建分支，“打开”）和“push -b --new-branch”（仅发布分支，而不是在主线）到“私人”，其中分支也必须合并到默认。

在这种情况下，增加的分叉数量会导致每个分叉“+2 个命令+1 个存储库”。

• 分支的变化：单个开发人员的存储库，许多命名分支（每个目标分支 + 每个任务分支）。 v.1 的小偏差 - 只有一个开发存储库，其中包含 Open 和 Private 命名分支（以及其他短期分支）。任务也（如第 1 页）在单独的分支中实现，该分支（无需推送）合并到所需的目标（开放和私有）。 用户可见 开放和私有存储库也必须使用 Push -b 进行更新，

在这种情况下增加分叉数量，每个分叉

• 基于补丁的模型需要“+1 个命令+1 个分支”。单一通用代码，所有更改都在“vanilla Open”代码库变更集之上执行。启用 MQ 后，仅在队列中应用补丁，将开放转换为私有。如果情况“存在于 Open 中，不得存在于 Private 中”，我们将进入 Core-Open-Private 3 级版本控制的情况。对于这种情况，必须使用核心之上的不同补丁集。 “不同的补丁集”可以是a）针对不同目标的不同命名分支以及手动应用和控制b）使用防护c）对于相当新鲜的Mercurial，可能有单独的队列，并且对于每个唯一的目标也有唯一的队列。任务可以像以前一样在分支中开发，也可以在 MQ 补丁中开发（稍后完成或不完成）

在这种情况下增加分叉数量，每个分叉需要“+1 个补丁”，也许“+1 个队列”（见上文） 。为了简单性和可管理性，我更喜欢带有警卫的单个队列

Answer 4

像往常一样，项目由一组模块组成。
根据我的经验，有时将一些模块放在单独的源代码控制存储库中会更好。例如，一些实用程序模块或核心模块，如 Web 框架或 DAO (ORM) 模块。在这种情况下，您可以按照应该的方式使用源代码控制中的分支 - 支持主干开发并支持同一源代码控制存储库中的每个发布版本，以便能够合并分支。

因此，我建议您重新设计应用程序模块的结构，以便将核心（开源）功能与商业（依赖于客户）定制分开。
因此，要管理开源和开放源代码。商业版本您需要有一个单独的组装过程 - 它们可以或多或少相似，甚至商业版本可以使用开源版本作为完整的工件集并扩展它们。

事实上，这是一个非常有趣的任务——去年我在这上面花了很多时间。我的决定是拥有一个具有功能齐全的 Maven 任务的核心存储库（开源）来发布它。并为每个客户提供一个单独的存储库，仅保留设计定制和定制。一些特定于客户的业务逻辑（只需在客户的 Spring XML 中使用别名来覆盖您的“核心”Spring 服务 - 请参阅 BeanDefinitionOverriding)我的客户的 maven-task 是基于 core-artifacts 的使用（通常扩展其中一些 - 例如参见 maven-war-plugin 允许扩展现有的 WAR）。以这种方式处理，您将永远不会在另一个分支中拥有同一类的克隆 - 您将使用它或扩展它，就像在应用程序中使用 log4j 类一样。您应该只是扩展开源版本。

另一个有趣的任务是如何管理配置文件。我建议您查看 Maven 远程资源插件 而不是默认的 < a href="http://maven.apache.org/plugins/maven-resources-plugin/" rel="nofollow">Maven 资源插件。它允许您拥有配置文件模板并将所有值移动到 maven 配置文件 这应该针对每个客户。并参见 Maven Tiles 插件 -它帮助我极大地简化了客户项目中的“pom.xml”（我可以重用maven构建和组装过程的“tiles”）