分布式版本控制系统和企业 - 一个很好的组合？ [关闭]

Question

我可以看到为什么分布式源代码控制系统（像Mercurial这样的DVCS）对开源项目有意义。

但它们对企业有意义吗？ （通过集中的源控制系统，如TFS）

DVCS的哪些特性使其更适合或更适合具有许多开发人员的企业？ （通过集中式系统）

Answer 1

我刚刚在一家大型银行公司推出了DVCS（本例中为Git），其中Perforce，SVN或ClearCase是选择的集中式VCS：
我已经知道了这些挑战（参见我之前的回答“ 我们能否最终转向企业软件中的DVCS？SVN仍然是'必须'用于开发吗？ ”）

我在三个方面受到挑战：

• 集中化 ：虽然分散模型有其优点（并允许私有提交或在没有网络的情况下工作，同时可以访问完整的历史记录），但仍需要一套清晰的集中式存储库，作为所有开发人员的主要参考。

• 身份验证 ：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，Apache通过LDAP设置对用户进行身份验证：这样，必须为这些repos上的任何git操作提供实际登录。
    Git通过其智能http协议提供它，不仅可以通过http pull （读），还可以通过http push （写）。

认证部分也通过post-receive钩子在Git级别得到加强，这确保了你推送到repo的至少一个提交具有“提交者名称”等于通过shh或h​​ttp协议检测到的用户名。
换句话说，您需要正确设置您的git config user.name ，否则您要对中央仓库进行的任何推送都将被拒绝。

。

• 授权 ：以前的设置（ssh或https）连线调用同一组perl脚本，名为gitolite ，带有as参数：
  • 这两个协议检测到的实际用户名
  • 用户想要执行的git命令（克隆，推送或拉取）

gitolite perl脚本将解析一个简单的文本文件 ，其中已设置授权（对所有存储库的读/写访问，或给定存储库中的分支，甚至存储库中的目录）。
如果git命令所需的访问级别与该文件中定义的ACL不匹配，则拒绝该命令。

---

上面描述了我需要为Git设置实现的内容，但更重要的是，它列出了在具有独特用户群的大公司中使DVCS设置需要解决的主要问题。

然后，只有这样，DVCS（Git，Mercurial，...）才能添加值，因为：

• 多个站点之间的数据交换 ：虽然这些用户都通过同一个Active Directory进行了身份验证，但它们可以位于世界各地（我所工作的公司通常在两个或三个国家/地区的团队之间进行开发）。 DVCS自然地用于在这些分布式团队之间有效地交换数据。

• 跨环境复制 ：负责身份验证/授权的设置允许在其他专用服务器上克隆这些存储库（用于集成测试，UAT测试，预生产和预部署）

• 流程自动化 ：克隆仓库的简便性也可以在一个用户的工作站上本地使用，使用“保护提交”技术和其他聪明的用途进行单元测试：请参阅“ 源仓库最聪明的用途是什么 ” 你见过吗？ “
  简而言之，您可以推送到第二个本地仓库，负责：

  • 各种任务（单元测试或代码的静态分析）
  • 如果这些任务成功，则推回主要回购
  • 而你仍然在第一个回购工作，而不必等待这些任务的结果。

。

• 杀手锏 ：任何DVCS自带的，其中最主要的合并 （曾经试图做一个复杂的合并工作流程SVN或者sloooowly合并6000个文件与ClearCase？）。
  仅此一点（合并）意味着您可以真正利用分支 ，同时能够始终将代码合并到另一个“主要”开发线上，因为您会这样做：
  • 首先在你自己的回购当地，不打扰任何人
  • 然后在远程服务器上，在中央仓库上推送该合并的结果。

Answer 2

至少在tfs 2013中，您可以与本地工作区断开连接。 分布式与集中式是由业务定义的，取决于正在开发的项目的需求和要求。

对于企业项目，将工作流和文档连接到代码更改的能力对于将业务需求和更高阶元素连接到解决特定更改，错误或功能添加的特定代码更改至关重要。

工作流和代码存储库之间的这种连接将TFS与仅代码存储库解决方案分开。 对于需要更高级别的项目审核的地方，只有像TFS这样的产品才能满足更多的项目审核要求。

可以在此处找到应用程序生命周期管理过程的概述。

http://msdn.microsoft.com/en-us/library/vstudio/fda2bad5(v=vs.110).aspx

Answer 3

我们在企业设置中面临的最大问题是缺乏基于路径的读取访问控制。 它是Git架构中固有的（我假设大多数DVCS），如果你有对存储库的读访问权，你就可以得到整个东西。 但有时一个项目需要一个稀疏的结账（即您希望版本控制敏感数据靠近源，或者您希望给第三方选择性地查看项目的一部分）。

开箱即用，Git没有提供任何权限 - 你已经有了编写自己的权限。

大多数流行的回购管理器GithubEnterprise，Gitlab，Bitbucket都提供基于分支的写入限制。 Gitolite允许更细粒度，提供基于路径（和更多）的写入限制。

我听说唯一支持读取访问的repo管理器是Perforce Helix，它在perforce后端重新实现了git协议，但我没有亲身体验过它。 这很有希望，但我会担心它与“普通”git的兼容性如何。

Answer 4

为了增加其他评论，我会发现你没有理由不能拥有一个企业中央存储库 。 从技术上讲，它只是另一个存储库，但它是您生产的产品。 我已经使用VCS的这种或那种形式超过30年了，我可以说切换到Mercurial就像一个城市男孩第一次呼吸清洁的乡村空气。

Answer 5

对于离线或慢速网络，DSCS（通常）比集中式系统更好。 它们往往更快，这对于进行大量签到的开发人员（使用TDD）来说真的很明显。

集中式系统最初更容易掌握，对于经验不足的开发人员来说可能是更好的选择。 DVCS允许您创建大量的迷你分支并隔离新功能，同时仍然可以在绿色编码样式上执行red-gree-refactor checkin。 同样，这是非常强大的，但只对相当精明的开发团队有吸引力。

如果你处理像数字资产和非文本文档（PDF和Word等）不可合并的文件，那么拥有一个支持独占锁的单一中央存储库是有意义的，因为它可以防止你陷入困境并手动合并。

我不认为开发人员或代码库大小的数量如此之多，两个系统都显示为支持大型源代码树和提交者数量。 但是对于大型代码库和项目，DVCS在快速创建分散的远程分支方面提供了很大的灵活性。 您可以使用集中式系统执行此操作，但您需要更加谨慎地处理它，无论好坏。

简而言之，需要考虑一些技术方面，但您还应该考虑团队的成熟度以及他们围绕SCCS的当前流程。

Answer 6

对我来说，他们提供的最大的东西就是速度。 对于最常见的操作，它们比集中式源控制快几个数量级。

工作断开连接也是一个巨大的优势。

Answer 7

绝对地，分布式源模型在企业中是有意义的，但它确实取决于团队的结构。

分布式源代码控制使您可以灵活地创建自己的工作流程。

想象一下，如果你愿意，一个更大的团队，其中有较小的团队在不同的功能分支上工作。

• 这些团队都可以拥有自己的中央存储库，并拥有自己的构建自动化/签入控制机制。
• 他们可以在任何地方工作，并随时备份他们的本地工作。
• 然后，他们可以选择他们想要在群组之间分享的签到。
• 他们可以拥有一个单独的集成商，在他们自己的机器上工作，执行合并， 而不会影响其他人。

这些是您可以通过传统的集中式服务器实现的功能，但正如@Brook指出的那样，集中式模型必须进行扩展，而分布式模型已经分片 ，因此不需要（或至少更少）垂直扩展任何服务器。

Answer 8

在切换到Mercurial之前，我们的团队使用TFS约3年。 HG的分支/合并支持比TFS好得多。 这是因为DVCS依赖于无痛的合并。

Answer 9

跨远程/断开连接的位置更好地同步