分布式版本控制系统和企业 – 一个很好的组合？

我明白了为什么分布式源代码pipe理系统（DVCS – 像Mercurial）对于开源项目是有意义的。

但是他们对一个企业有意义吗？ （通过诸如TFS的集中式源控制系统）

DVCS的哪些function使其更好或更差，适合有许多开发人员的企业？ （通过中央系统）

Answer 1

我刚刚在一家大型银行公司推出了DVCS（Git），Perforce，SVN或ClearCase是集中的VCSselect：
我已经知道了这些挑战（请参阅我以前的回答：“ 我们能否最终迁移到企业软件中的DVCS？SVN是否仍然是开发必须的 ”）

我受到三方面的挑战：

• 集中化 ：虽然分散化模式有其优点（并且允许私人提交或者在访问完整历史的情况下在没有networking的情况下工作），但是仍然需要有一组明确的集中回购，作为所有开发者的主要参考。

• authentication ：DVCS允许你“签字”（提交）你的代码……几乎任何人（作者“ foo ”，电子邮件“ [e-mail] ”）。
  你可以做一个git config user.name foo ，或者git config user.name whateverNameIFeelToHave ，然后把所有你提交的伪名称提交给它。
  这与大企业所使用的独特的集中式“活动目录”用户参考不兼容。

• 授权 ：默认情况下，您可以克隆，推送或拉出任何存储库，并修改任何分支或任何目录。
  对于敏感的项目，这可能是一个阻碍问题（银行业通常是非常保护一些定价或数量algorithm，这需要严格的读/写访问为数有限的人）

答案（Git设置）是：

• 集中化 ：为所有用户都可以访问的存储库build立了唯一的服务器。
  备份一直在照顾（每天增量，每周充满）。
  DRP（灾难恢复计划）已实施，另一个站点上有另一台服务器，并通过SRDF实现实时数据复制。
  这个设置本身与您所需的参考或工具的types（DVCS，Nexus repo或Hudson主调度器，或…）无关：任何可能对生产发布至关重要的工具都需要安装在服务器上备份和DR。

。

• authentication ：只有两个协议允许用户访问主要的回购：
  • 基于SSH，与公/私钥：
    • 对组织外部的用户有用（如离岸开发），
    • 对于Active Directorypipe理员不想创build的通用帐户非常有用（因为它将是一个“匿名”帐户）：真正的人员必须对该通用帐户负责，那将是拥有私钥的人员
  • 基于https的，用Apache通过LDAP设置对用户进行身份validation：这样，必须为这些回购站上的任何git操作提供实际login。
    Git提供了它的智能http协议 ，不仅可以通过http进行pull （读取），还可以通过http进行push （写入）。

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

。

• 授权 ：以前的设置（SSH或HTTPS）都被连接到调用相同的一组perl脚本，命名为gitolite ，作为参数：
  • 这两个协议检测到的实际用户名
  • git命令（克隆，推或拉）用户想要做的

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

---

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

然后，只有这样，一个DVCS（Git，Mercurial，…）可以添加值，因为：

• 在多个站点之间进行数据交换 ：虽然这些用户都是通过相同的Active Directory进行身份validation的，但他们可以位于全球（我所工作的公司通常在两个或三个国家的团队之间进行开发）。 DVCS自然是为了在这些分布式团队之间有效地交换数据而做出的。

• 跨环境复制 ：一个负责authentication/授权的设置允许将这些存储库克隆到其他专用服务器（用于集成testing，UATtesting，预生产和预部署的目的）

• 过程自动化 ：克隆一个回购的容易性也可以在一个用户的工作站上本地使用，以“保护的提交”技术和其他聪明用途进行unit testing：请参阅“ 源代码库的最聪明的使用你见过？ “
  总之，你可以推到第二个本地回购负责：

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

。

• 杀手级特性 ：任何DVCS都带有这些特性，主要是合并 （曾经试图用SVN做一个复杂的合并工作stream程，或者将6000个文件与ClearCase合并）。
  单独的（合并）意味着你可以真正利用分支 ，而且随时可以将代码合并到另一个“主要”开发线上，因为你可以这样做：
  • 首先在你自己的回购站内进行，而不会打扰任何人
  • 然后在远程服务器上，在中央仓库上推送合并的结果。

Answer 2

要添加到其他评论，我会观察到没有理由你不能有企业中央信息库 。 从技术上讲，这只是另一个存储库，但它是你从哪里生产的。 我已经使用了VCS的这种或那种forms30多年了，我可以说转换到Mercurial就像是一个城市男孩第一次呼吸干净的乡村空气。

Answer 3

与离线或慢速networking的集中式系统相比，DSCS有更好的performance（通常）。 他们往往会更快，这对开发人员（使用TDD）进行大量签入非常重要。

集中式系统最初比较容易掌握，对于经验较less的开发人员来说可能是更好的select。 DVCS允许你创build大量的迷你分支，并隔离新的function，同时仍然进行绿色风格的编码格式的红色重构检查。 这个function非常强大，但对于相当精明的开发团队来说只有吸引力。

如果您处理的文件不像数字资产和非文本文档（PDF和Word等），因为它可以避免让自己陷入混乱和手动合并的情况下，拥有一个单独的中央存储库来支持排它锁是非常有意义的。

我不认为开发人员的数量或代码库的大小，这两个系统已被certificate支持大型源代码树和提交者的数量。 但是，对于大型代码库和项目，DVCS为快速创build分布式远程分支提供了很大的灵活性。 你可以用集中式的系统来做到这一点，但是你需要更多地考虑它是​​好的还是坏的。

简而言之，需要考虑一些技术方面的问题，但是您也应该考虑一下您的团队的成熟度以及他们目前围绕SCCS的stream程。

Answer 4

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

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

工作stream和代码库之间的这种连接将TFS从代码库唯一的解决scheme中分离出来。 对于一些需要更高级别的项目审计的地方，只有像TFS这样的产品才能满足更多的项目审计需求。

应用程序生命周期pipe理过程的概述可以在这里find。

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

Answer 5

Git在企业环境中面临的最大问题是缺乏基于path的读取访问控制。 这是Git的架构（我将假设大多数DVCS）固有的，如果你有读取权限的存储库，你会得到整个事情。 但是有时候一个项目需要一个稀疏的结账（即你想要控制敏感数据靠近源代码，或者你想给第三方一个select性的视图）。

开箱即用，Git不提供任何权限 – 你有自己的钩子。

大多数stream行的repopipe理器GithubEnterprise，Gitlab，Bitbucket提供了基于分支的写入限制。 Gitolite允许更精细的粒度，提供基于path（和更多）的写入限制。

我听说支持读访问的唯一repopipe理器是Perforce Helix，它在perforce后端上重新实现了git协议，但是我没有实际操作经验。 这是有希望的，但我会担心与“普通”混帐是多么的兼容。

Answer 6

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

断线工作也是一个巨大的优势。

Answer 7

绝对的分布式源模型在企业中是有意义的，但是它依赖于团队的结构。

分布式源代码控制让您可以灵活地创build自己的工作stream程。

想象一下，如果你愿意的话，可以组build一个更大的团队，其中的小团队在不同的function分支上工作。

• 这些团队都可以拥有自己的中央仓库，并拥有自己的构build自动化/签入控制机制。
• 他们可以在任何地方工作，并随时备份他们当地的工作。
• 然后，他们可以select他们希望在团体之间分享的签证。
• 他们可以有一个独立的集成人员，在他们自己的机器上工作，进行合并， 而不会影响他人。

这些是用传统的集中服务器可以实现的，但是@Brook指出，集中式模型必须扩展，而分布式模型已经被分解了，所以没有（或至lessless）需要垂直扩展任何服务器。

Answer 8

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

Answer 9

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