我能理解为什么分布式版本控制系统（DVCS - 例如Mercurial）对于开源项目是有道理的。
但是对于企业来说，它们是否也有意义呢？（相比于像TFS这样的集中式版本控制系统）
一个DVCS具有哪些特点使其更适合或不适合拥有许多开发人员的企业使用呢？（相比于集中式系统）
分布式版本控制系统和企业——一个好的结合吗？
52
- Raj Rao
1
2离题了，但我认为缩写DVCS比DSCS更常见/被接受。 - Brook
9个回答
96
我刚在一家大型银行引入了一个分布式版本控制系统（这里是Git），在此之前，Perforce、SVN或ClearCase是中央 VCS 的首选：
我已经知道了其中的挑战（请参见我的先前回答 "Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?"）。
我面临了三个方面的挑战：
上面描述了我需要在Git设置中实现的内容，但更重要的是，它列出了需要解决的主要问题，在一个有独特用户群体的大公司中，DVCS设置才有意义。
只有在这种情况下，DVCS(Git、Mercurial等)才能增加价值，原因如下:
- 多个站点之间的数据交换:虽然这些用户都通过同一个活动目录进行身份验证，但他们可以位于世界各地(我曾为的公司通常在两三个国家的团队之间开展开发)。DVCS天然就是为了在这些分布式团队之间高效地交换数据而设计的。 - 跨环境复制:一个负责身份验证/授权的设置允许在其他专用服务器上克隆这些存储库(用于集成测试、UAT测试、预生产和预部署等) - 进程自动化:你可以很容易地克隆一个repo并在一个用户的工作站上使用"guarded commits "技术进行单元测试等，以及其他巧妙的方法：见“What is the cleverest use of source repository that you have ever seen?”。简而言之，你可以推送到第二个本地repo，负责各种任务(代码的单元测试或静态分析)，如果这些任务成功完成，就推回到主repo，而你仍然可以在第一个repo中继续工作，而无需等待这些任务的结果。
我已经知道了其中的挑战（请参见我的先前回答 "Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?"）。
我面临了三个方面的挑战：
集中化：分散模型有其优点（允许私人提交或在没有网络的情况下使用完整历史记录），但仍需要一组明确的集中化存储库，作为所有开发人员的主要参考。
身份验证：DVCS允许您将代码“签名”（提交）为...几乎任何人（作者“
foo”，电子邮件“foo@bar.com”）。
您可以执行git config user.name foo或git config user.name whateverNameIFeelToHave，并在其中具有虚假名称的所有提交。
这与大型企业使用的唯一集中式“Active Directory”用户参考不相容。授权：默认情况下，您可以克隆、推送或拉取任何存储库，并修改任何分支或任何目录。
对于敏感项目，这可能是一个阻碍问题（银行业通常非常保护某些定价或量化算法，需要非常少的人进行严格的读/写访问）
Git设置的答案是：
- 集中化：为了让所有用户都能够访问，每个仓库都设置了一个独特的服务器。
备份已经得到了处理（每天增量备份，每周全量备份）。
已经实施了DRP（灾难恢复计划），在另一个站点上有第二台服务器，并通过SRDF实现了实时数据复制。
这种设置本身与您需要的参考或工具类型无关（DVCS、Nexus repo、主Hudson调度程序等）：任何对于生产发布至关重要的工具都需要安装在具备备份和DR的服务器上。
.
- 认证：只有两种协议允许用户访问主要仓库：
- 基于ssh，使用公钥/私钥：
- 适用于组织外部的用户（如离岸开发），
- 对于Active Directory管理员不想创建的通用帐户非常有用（因为它将是一个“匿名”帐户）：一个真实的人必须负责那个通用帐户，这就是拥有私钥的人
- 基于https，在LDAP设置下通过Apache认证用户：这样，任何git操作都必须提供实际的登录信息。
Git通过其智能http协议提供此功能，允许不仅通过http执行pull（读取），而且还可以通过http执行push（写入）。
- 基于ssh，使用公钥/私钥：
在Git层面上，认证部分也通过post-receive钩子进行了加强，确保您推送到存储库中的至少有一个提交者名称等于通过shh或http协议检测到的用户名。
换句话说，您需要正确设置git config user.name，否则您想要推送到中央存储库的任何推送都将被拒绝。
.
- 认证：先前的设置（ssh或https）均被连接到同一组Perl脚本gitolite，并带有以下参数：
- 通过这两种协议检测到的实际用户名
- 用户想要执行的git命令（克隆、推送或拉取）
gitolite Perl脚本将解析一个简单的文本文件，其中设置了授权（所有存储库的读/写访问权限，或给定存储库中的分支的访问权限，甚至是存储库中目录的访问权限）。
如果git命令所需的访问级别不符合该文件中定义的ACL，则该命令将被拒绝。
上面描述了我需要在Git设置中实现的内容，但更重要的是，它列出了需要解决的主要问题，在一个有独特用户群体的大公司中，DVCS设置才有意义。
只有在这种情况下，DVCS(Git、Mercurial等)才能增加价值，原因如下:
- 多个站点之间的数据交换:虽然这些用户都通过同一个活动目录进行身份验证，但他们可以位于世界各地(我曾为的公司通常在两三个国家的团队之间开展开发)。DVCS天然就是为了在这些分布式团队之间高效地交换数据而设计的。 - 跨环境复制:一个负责身份验证/授权的设置允许在其他专用服务器上克隆这些存储库(用于集成测试、UAT测试、预生产和预部署等) - 进程自动化:你可以很容易地克隆一个repo并在一个用户的工作站上使用"guarded commits "技术进行单元测试等，以及其他巧妙的方法：见“What is the cleverest use of source repository that you have ever seen?”。简而言之，你可以推送到第二个本地repo，负责各种任务(代码的单元测试或静态分析)，如果这些任务成功完成，就推回到主repo，而你仍然可以在第一个repo中继续工作，而无需等待这些任务的结果。
.
- VonC
1
1请参阅http://programmers.stackexchange.com/questions/85845/why-big-companies-use-perforce。 - VonC
1
在企业中，分布式源代码模型确实是有意义的，但它取决于团队的结构。
分布式源代码控制使您能够灵活地创建自己的工作流程。
想象一下，一个更大的团队，其中包括在单独的功能分支上工作的小团队。
- 这些团队都可以拥有自己的中央存储库，具有自己的构建自动化/签入控制机制。
- 他们可以在任何地方工作，并在需要时备份本地工作。
- 然后，他们可以选择要在组之间共享的签入。
- 他们可以有一个单独的个人集成者，在自己的机器上执行合并，而不会影响其他人。
这些都是您可以通过传统的集中式服务器实现的事情，但正如@Brook所指出的那样，集中式模型必须进行扩展，而分布式模型已经被分片，因此不需要（或至少需要较少）垂直扩展任何服务器。
- Khanzor
5
你可能想要了解TFS。团队项目可以基于功能和/或发布分支进行工作。TFS2010更进一步，使合并变得更加容易，并跟踪哪些分支有哪些错误修复。你总是能够在本地进行合并。 - John Saunders
正如我所说，你可以使用集中式服务器完成这些任务。但是你无法在断网的情况下工作。此外，TFS 是昂贵的，而 DVCS 是免费的。 - Khanzor
你可能想在你的回答中加上“免费”这个词。但是，我可以使用TFS脱机工作。你为什么认为我不能呢？ - John Saunders
你不能真正使用TFS离线工作（或在此展示如何创建分支、执行checkin、将项目还原到3个changesets之前的状态，而不连接网络）。 - Luxspes
2在TFS中断开连接时，您无法检入代码。在TFS中断开连接时，您无法还原到以前的代码版本。在TFS中断开连接时，您无法进行二分查找以查找引入错误的修订版。在TFS中断开连接时，您无法保留代码。在TFS中断开连接时，您无法将您的代码与最新版本进行比较。在TFS中断开连接时，您无法进行分支和合并。当您在TFS中断开连接时，唯一能做的事情就是编辑您的代码。 - jammycakes
1
除了其他评论，我认为你可以拥有一个“企业中央仓库”。从技术上讲，它只是另一个存储库，但它是您生产所需的。我使用各种版本控制系统已经30多年了，我可以说切换到Mercurial就像是一个城市男孩第一次呼吸新鲜空气一样。
- Peter Rowell
1
DSCS通常比离线或慢速网络的集中式系统具有更好的故事。它们往往更快，这对于经常进行检查的开发人员（使用TDD）来说非常明显。
集中式系统在最初阶段可能更容易理解，并且可能是不太有经验的开发人员的更好选择。DVCS允许您创建许多迷你分支并隔离新功能，同时仍然可以进行红绿重构检入绿色编码风格。再次强调，这非常强大，但只对相当精明的开发团队有吸引力。
如果您处理不可合并的文件（如数字资产和非文本文档（PDF和Word等），则为支持独占锁定而拥有单个中央存储库是有意义的，因为它可以防止您陷入麻烦并手动合并。
我认为开发人员数量或代码库大小并不是那么重要，两种系统都已被证明可以支持大型源树和提交者数量。但是，对于大型代码库和项目，DVCS在快速创建分散的远程分支方面提供了很大的灵活性。您可以使用集中式系统完成此操作，但需要更加谨慎，这既有利又有弊。
简而言之，有一些技术方面需要考虑，但您还应考虑团队的成熟度以及他们当前在SCCS周围的流程。
集中式系统在最初阶段可能更容易理解，并且可能是不太有经验的开发人员的更好选择。DVCS允许您创建许多迷你分支并隔离新功能，同时仍然可以进行红绿重构检入绿色编码风格。再次强调，这非常强大，但只对相当精明的开发团队有吸引力。
如果您处理不可合并的文件（如数字资产和非文本文档（PDF和Word等），则为支持独占锁定而拥有单个中央存储库是有意义的，因为它可以防止您陷入麻烦并手动合并。
我认为开发人员数量或代码库大小并不是那么重要，两种系统都已被证明可以支持大型源树和提交者数量。但是，对于大型代码库和项目，DVCS在快速创建分散的远程分支方面提供了很大的灵活性。您可以使用集中式系统完成此操作，但需要更加谨慎，这既有利又有弊。
简而言之，有一些技术方面需要考虑，但您还应考虑团队的成熟度以及他们当前在SCCS周围的流程。
- Ade Miller
2
请注意，TFS支持代理服务器。请参阅http://msdn.microsoft.com/en-us/library/ms245478.aspx。此外，是什么阻止在TFS中创建“迷你分支”？它具有门控检入、搁置等功能。 - John Saunders
@John Saunders：一个 shelveset 实际上是一个被限制在单个版本的迷你分支。Git/Mercurial 允许任意长度的即兴迷你分支。而且，保护式检入与创建迷你分支毫无关系。 - jammycakes
1
至少在使用tfs 2013时，您可以使用本地工作区脱机工作。分布式与集中式是由业务定义的，并取决于正在开发的项目的需求和要求。
对于企业项目而言，将工作流程和文档连接到代码更改可能是关键的，可将业务需求和高级元素连接到特定的代码更改，以解决特定的更改、错误或功能添加。
工作流程与代码库之间的这种连接将TFS与仅为代码库的解决方案区分开来。对于一些需要更高级别项目审核的地方，只有像TFS这样的产品才能满足更多的项目审核要求。
应用程序生命周期管理过程的概述可在此处找到。
对于企业项目而言，将工作流程和文档连接到代码更改可能是关键的，可将业务需求和高级元素连接到特定的代码更改，以解决特定的更改、错误或功能添加。
工作流程与代码库之间的这种连接将TFS与仅为代码库的解决方案区分开来。对于一些需要更高级别项目审核的地方，只有像TFS这样的产品才能满足更多的项目审核要求。
应用程序生命周期管理过程的概述可在此处找到。
http://msdn.microsoft.com/en-us/library/vstudio/fda2bad5(v=vs.110).aspx
- Mike Beeler
1
在企业环境中，Git 的最大问题是缺乏基于路径的读取权限控制。这在 Git 的架构中是固有的（我认为大多数分布式版本控制系统也是如此），如果您获得了对存储库的读取权限，则可以获取整个存储库。但有时项目需要稀疏检出（即，您希望在源代码附近进行敏感数据的版本控制，或者希望为第三方提供项目的部分选择性视图）。
Git 默认不提供权限 - 您可以编写自己的钩子。
大多数流行的存储库管理器 GithubEnterprise、Gitlab、Bitbucket 提供基于分支的写入限制。Gitolite 允许更细粒度地提供基于路径（以及更多）的写入限制。
我听说唯一支持读取权限的存储库管理器是 Perforce Helix，它在 perforce 后端之上重新实现了 git 协议，但我没有亲身体验过。它很有前途，但我担心它与“普通”git的兼容性。
Git 默认不提供权限 - 您可以编写自己的钩子。
大多数流行的存储库管理器 GithubEnterprise、Gitlab、Bitbucket 提供基于分支的写入限制。Gitolite 允许更细粒度地提供基于路径（以及更多）的写入限制。
我听说唯一支持读取权限的存储库管理器是 Perforce Helix，它在 perforce 后端之上重新实现了 git 协议，但我没有亲身体验过。它很有前途，但我担心它与“普通”git的兼容性。
- ddimitrov
0
对我来说，它们提供的最大优势是速度。在最常见的操作中，它们比集中式源代码控制快了数个数量级。
脱机工作也是一个巨大的优点。
脱机工作也是一个巨大的优点。
- Brook
11
TFS允许您脱机工作。 - John Saunders
@John Saunders：我的使用TFS的经验是，如果在启动VS时让它知道你已经断开连接，它就能正常工作，但是一旦上线后连接中断，则极不稳定。此外，除非2010年有新功能，否则在断开连接时无法查看历史记录、分支、合并、注释或签入。所以，至少不能像DVCS那样进行操作。 - Brook
1@John Saunders：具体来说，我是在与'08服务器对抗，这不是我或我的公司特有的问题，只需问一下就知道。此外，正如我所说，当您断开连接时，除了“签出”之外，您无法使用源代码控制做任何事情，因此它与DVCS不可比较。我不明白您在关于DVCS的问题中发布有关TFS的评论的目的是什么，最多是离题，最坏的情况是拖延时间。 - Brook
1@John Saunders：OP 特别提到了 Mercurial，而 Mercurial 和 Git 具有非常相似的功能，所以我在回答这个问题。使用分布式版本控制系统（DVCS）离线时，你可以做什么，而在 TFS 中无法做到呢？分支、合并、查看历史记录、注释/责备、检入（换句话说，几乎所有除了与其他开发人员交换代码之外的事情，如果你能连接到另一个开发人员，甚至可以在不连接到服务器的情况下完成）。 - Brook
1或者你可以使用USB存储设备与另一个开发人员共享你的代码...换句话说，使用分布式版本控制系统，即使在断网的情况下也可以完成所有操作（而在TFS 2010中，几乎无法在断网的情况下进行任何操作）。TFS拥有许多其他出色的功能（例如工作项、过程模板、报告等），但在版本控制领域中它并不是最佳选择。 - Luxspes
显示剩余6条评论
0
我们团队在使用TFS约3年后切换到了Mercurial。HG的分支/合并支持比TFS好得多。这是因为DVCS依赖于无痛合并。
- Jim Bolla
3
比起哪个版本的TFS更好？你尝试过TFS 2010新增的分支和合并功能吗？请参考http://msdn.microsoft.com/en-us/magazine/gg598921.aspx和http://msdn.microsoft.com/en-us/library/ms181423.aspx。 - John Saunders
这是TFS 2008。我没有使用过2010版本，无法进行比较。我们对HG非常满意，除非上级管理层强制要求，否则不会考虑切换回去。此外，由于它的脱机特性，我很容易将克隆推送到USB驱动器并带回家里继续工作，这也很方便。 - Jim Bolla
TFS 2010 Service Pack 1仍将不在直接父/子关系中的分支之间的合并视为无基础合并。换句话说，合并两侧之间的每个差异都被报告为冲突，并且没有指示代码是在一侧添加还是在另一侧删除。分布式源代码控制工具没有这种限制。 - jammycakes
-1
更好的跨远程/断开连接位置同步。
- Ondrej Tucny
6
比什么更好？你是在说使用TFS时存在问题吗？ - John Saunders
我的意思是，您可以在不同的位置保留存储库的多个副本，并让版本控制系统(VCS)无缝地将它们同步。我并不是说这是TFS的问题。我没有使用TFS的经验，可以与Subversion等系统进行比较。 - Ondrej Tucny
谢谢。但是与中央仓库相比，为什么这是一个好的功能呢？ - John Saunders
我们目前面临的一个真实版本控制场景是：我们的客户希望我们将源代码存储在他们的系统中。开发团队位于我们的办公室，但仍然需要不时地现场工作。使用分布式版本控制系统（DVCS），可以有两个“主”存储库副本，并且它们可以进行同步。即使在没有直接网络连接的情况下，DVCS也不应该成为问题。 - Ondrej Tucny
谢谢，但我仍然不明白为什么我不应该只给客户提供源代码副本，而保持存储库集中化。请回想一下，这个问题是关于DVCS的“企业”使用的。你的情况似乎不像“企业”使用，而更像咨询情况。 - John Saunders
这是一个“企业级”使用 - 实际上是一个“双重企业级”使用。 - Ondrej Tucny
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接