像Git这样的DVCS是否适合使用持续集成的团队？

Question

我的团队的开发流程基于continuous integration。我们创建的唯一分支是维护分支，当我们发布时，开发人员应该定期（每天，如果不经常）提交到主干，这样每个人的工作总是集成，不断测试，以及所有好东西。

我对DVCS的理解是它很适合分支。几年前我在一个非常有用的团队中工作，因为每个开发都是在一个分支上完成的，只有在完成和测试时才合并。但这与持续整合的理念不同。

但在我看来，对于使用持续集成的团队而言，像Git这样的DVCS工具的常规功能并不是特别相关，如果合并更改需要额外的步骤，甚至可能会阻碍持续集成过程可能会被遗忘。

我确信DVCS还有其他好处（例如，提交非常快，因为它是本地的，可能与主分支合并可能在后台发生，而开发人员继续工作）。

但对于这个问题，我对使用DVCS和持续集成的团队如何协调这两个看似相互矛盾的哲学感兴趣。我主要是想听听那些真正这样做的人。

Answer 1

实际上DVCS使持续集成变得更加容易。

使用中央VCS，每个开发人员都有权直接在trunk中提交，因此他可以提交错误的代码。 CI将在事后检测到它。因此，即使使用CI，也可能会破坏行李箱。

另一方面，DVCS世界的基本操作是分支和合并。因为合并是明确的并且是一个单独的进程而不是提交到主干，所以可以始终检查合并之前的结果。我没有Git的经验，但是在PQM工具的帮助下，Bazaar VCS的开发人员已成功使用这项技术至少3。5年。

基本上PQM工作流程如下所示：开发人员发布他的分支以便可以合并，然后他通过合并指令向PQM机器人发送特殊电子邮件。当PQM收到合并请求时，它会创建一个单独的集成分支（trunk的副本），然后合并开发人员的分支并对生成的代码运行测试。如果所有测试都通过，那么集成分支将被推送到主干，否则开发人员将收到一封包含失败测试日志的电子邮件。

为Bazaar项目运行所有测试需要时间，但测试是在单独的服务器上按需执行的。开发人员不会被合并阻止，并且可以继续处理其他任务。

作为基于PQM的合并工作流程的结果，bzr主干永远不会被破坏（至少只要有足够的接受和回归测试）。

Answer 2

由于所有DVCS都可以与使用集中式存储库的工作流一起使用，因此没有问题。策略规定开发人员必须将其更改推送到中央存储库，其方式与策略规定对非分布式VCS的提交完全相同。允许开发人员编辑补丁集的其他工具不以任何方式阻碍，实际上使生成可维护代码库变得更加容易。

Answer 3

使用像Git这样的DVCS并不会阻止您定期向中央存储库提交。但是，它确实意味着您可以在本地进行中间提交，并且只有在完成后才将更改推送到中央存储库。

这样，即使在实现功能的一半时，您也可以从源代码控制中获益，而不会破坏其他开发人员的构建。

Answer 4

Hudson等持续集成工具支持DVCS，因此我怀疑这可以协调持续集成与分布式版本控制。

首先，我认为使用DVCS等主题分支工作流CI等工作流可能不那么必要。其次，您可以设置（单个，中央）持续集成存储库，在准备就绪时将其推送到该存储库，并挂钩执行CI。

---

已添加07-08-2009：

例如，请参阅GitHub博客上的Continuous Integration Spring Cleaning帖子。

Answer 5

我发现的两个想法有助于解释这一点：

• DVCS将提交与合并分开。
• CI针对您选择的存储库运行。

因此，问题的核心是如何将合并转换为您希望运行CI工具的存储库。您可以选择在启动时只有一个存储库。