哪个版本控制支持在多个版本中合并？

Question

想象一下，您有一个大型软件项目，您必须同时支持多个分支（发布）。例如，您在网站上有一个生产版本，一个目前由客户测试的集成测试版本，一个用于本地系统测试的测试版本，以及一个开发人员正在攻击新功能的开发版本。

哪种版本控制系统支持此设置？我主要担心的是它应该支持不同版本之间的合并 - 如果你在生产版本中修复了一个紧急错误，你也不想查看所有其他版本并手动修复错误5次。

如果您有答案，我希望了解您应用它的项目有多大以及您拥有的经验。我正在寻找一个明确支持的系统 由开发人员合并 - 应用脚本的解决方案 建立经理等不会帮助我们。 （太危险了;合并应该完成 由开发人员知道最好做什么后立即开发。） 非常感谢！

Answer 1

我认为大多数（如果不是全部）现代SCM都可以做到这一点。不一定是自动的，尽管有些脚本可以非常轻松地处理它。

在工作中，我们使用Perforce，我们手动完成集成（由Perl脚本帮助复制更改列表信息）。我们会仔细选择要发布的更改列表（例如，我们可以放弃有风险的更改列表） 对于大多数分布式VCS（Mercurial，Bazaar，可能是Git等），与多个分支（或克隆）一起工作是自然的工作流程。

Answer 2

根据我与颠覆工作合并的经验，但是非常痛苦（尽管我听说过更新的版本在这方面更好）。 Git和Mercurial合适地合并没有任何问题。

Answer 3

Clearcase将处理多个分支和修订，并在任何/所有这些之间进行合并。您可以随意定义分支，标记为您希望的分支，并与这些分支合并。毋庸置疑，这可能会让非常变得复杂，IBM提供merge manager来帮助您。您可以以图形方式显示分支（如果有帮助）。

Clearcase非常强大，但管理相对复杂且耗时。

Answer 4

Team Foundation Server通过合并支持任意数量的分支。虽然它很好，但2010版本的功能使分支更加引人注目。请参阅10-4 Episode 4: No More Parallel Development Pain。

Answer 5

如果你真的想要处理多个版本但没有遭受Clearcase的痛苦，你应该尝试Accurev或PlasticSCM之类的东西。

Accurev处理它的流是非常强大的，你必须习惯它们，但是一旦你做到这一点非常非常强大。

塑料在处理无限数量的分支（及其相应的合并）方面更强大，说起来容易做起来难。你已经为good-ol CC提到了所有的灵活性，但没有神秘的命令或奇怪的配置。

这里你有分支资源管理器跟踪多个分支

Answer 6

这个问题的答案是第一个过程，第二个是工具链。

您需要决定如何访问已知版本（例如“生产中的内容？”），您希望如何更改这些版本以及如何将更改传播到其他版本。

Subversion-Or-Better的大多数VCS系统都支持常见的工作流程。这是一个常见的：

1. 发展在主干上
2. 当发布时，标记主干，例如1.3.0
3. 在您制作的代码处创建主干的分支，例如1.3.x中
4. 根据''tag''（例如1.3.0）
发布代码
5. 继续在主干上开发新功能
6. 如果您需要修复生产中的错误，请查看分支并进行修复。正常释放，创建新标签（例如1.3.1）。
7. 根据需要将更改从您的分支合并回主干
8. 重复步骤6＆amp; 7，直到你的下一个版本发布。

这是另一种常见做法：

1. 发展在主干上
2. 当发布时，请标记主干
3. 根据''标签'（例如1.3.0）
发布到生产中
4. 如果发现错误，请创建一个分支以针对标记修复该错误
5. 提交新分支，并重新标记（例如1.3.1）
6. 将该分支合并回主干
7. 重复步骤4,5和＆amp; 6每当你发现错误时

这些非常常见且易于实施/理解;大多数版本控制系统都很容易支持它们。如果您获得更复杂的流程，您将减少可用的工具集，但可能拥有更多功能。

Answer 7

可以配置Telelogic CM Synergy/CM以支持此类设置。

好处是，如果文件在这些版本中保持不变，所有“更高”版本都会自动更新，而无需开发人员或构建管理器操作。如果更改了修改后的文件，则会在签入时立即通知开发人员，并且必须合并这些内容。它支持将相关更改分组为任务和更改请求，并为这些更改提供相关的跟踪系统。

缺点是它真的大而慢，需要大量的构建时间并且eclipse集成几乎无法使用。您可能需要每5或10位开发人员使用一名全职构建管理员。