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

我明白为什么分布式源代码控制系统（DVCS - 如 Mercurial）对于开源项目有意义。

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

DVCS 的哪些功能使其更适合或更不适合拥有众多开发人员的企业？ （通过集中式系统）

我刚刚在一家大型银行公司引入了 DVCS（本例中为 Git），其中 Perforce、SVN 或 ClearCase 是集中式 VCS 的选择：
我已经知道这些挑战（请参阅我之前的回答“我们最终可以在企业软件中转向 DVCS 吗？ SVN 仍然是开发的“必备”吗？ https://stackoverflow.com/questions/3597747/can-we-finally-move-to-dvcs-in-corporate-software-is-svn-still-a-must-have-for/3597851#3597851")

我在三个方面受到了挑战：

• 集权：虽然去中心化模型有其优点（并且允许私人提交或在没有网络的情况下工作，同时可以访问full历史），仍然需要有一套明确的集中repos，作为所有开发人员的主要参考。

• 验证：DVCS 允许您以几乎任何人的身份“签署”（提交）您的代码（作者“foo“， 电子邮件 ”[email protected] /cdn-cgi/l/email-protection").
  你可以做一个git config user.name foo, or git config user.name whateverNameIFeelToHave，并让所有提交都包含虚假名称。
  这与大型企业使用的独特的集中式“Active Directory”用户参考并不能很好地结合起来。

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

答案（对于 Git 设置）是：

• 集权：已为任何必须可访问的存储库设置了唯一的服务器all users.
  备份一直在照顾（每天增量，每周完整）。
  已实施DRP（灾难恢复计划），在另一个站点上有第二台服务器，并通过实时数据复制SRDF http://en.wikipedia.org/wiki/SRDF.
  此设置本身与您所需的引用或工具的类型无关（DVCS、Nexus 存储库、主 Hudson 调度程序，或...）：任何对于发布到生产环境至关重要的工具都需要安装在服务器上具有备份和灾难恢复功能。

.

• authentication: only two protocols allow users to access the main repos:
  • ssh based, with public/private key:
    • 对于组织外部的用户有用（例如离岸开发），
    • 和有用的genericActive Directory 管理员不想创建的帐户（因为它将是“匿名”帐户）：必须由真人负责该通用帐户，并且该帐户将是拥有私钥的帐户
  • 基于 https，Apache 通过 LDAP 设置对用户进行身份验证：这样，必须为这些存储库上的任何 git 操作提供实际的登录信息。
    Git 提供了它的智能http协议 http://progit.org/2010/03/04/smart-http.html，不仅允许pull（读）通过http，而且还push（写）通过http。

身份验证部分也在 Git 级别通过post-receive钩子确保最后一个您推送到存储库的提交的“提交者名称”等于通过 shh 或 http 协议检测到的用户名。
换句话说，您需要设置您的git config user.name正确，否则您想要向中央存储库进行的任何推送都将被拒绝。

.

• authorization: both previous settings (ssh or https) are wired to call the same set of perl script, named gitolite https://github.com/sitaramc/gitolite, with as parameters:
  • 这两个协议检测到的实际用户名
  • 用户想要执行的 git 命令（克隆、推送或拉取）

The gitolite perl 脚本将解析一个简单的文本文件 https://github.com/sitaramc/gitolite/blob/pu/doc/3-faq-tips-etc.mkd#_security_access_control_and_auditing其中已设置授权（所有存储库的读/写访问权限，或给定存储库中的分支，甚至存储库中的目录的读/写访问权限）。
如果 git 命令所需的访问级别与该文件中定义的 ACL 不匹配，则该命令将被拒绝。

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

然后，也只有到那时，DVCS（Git、Mercurial 等）才能添加值，因为：

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

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

• 过程自动化：您可以轻松地克隆存储库，也可以在一个用户的工作站上本地使用，通过“受保护的提交”技术和其他巧妙的用途进行单元测试：请参阅“您见过的源存储库最巧妙的用法是什么？ https://stackoverflow.com/questions/3209208/what-is-the-cleverest-use-of-source-repository-that-you-have-ever-seen".
  简而言之，您可以推送到第二个本地存储库，负责：

  • 各种任务（单元测试或代码静态分析）
  • 如果这些任务成功，则返回主存储库
  • while您仍在第一个存储库中工作，而不必等待这些任务的结果。

.

• killer features https://stackoverflow.com/questions/3900015/distributed-version-control-killer-applications: Any DVCS comes with those, the main one being merging (ever tried to do a complex merge workflow with SVN? Or sloooowly merge 6000 files with ClearCase?).
  That alone (merging) means you can really take advantage of branching https://stackoverflow.com/questions/2100829/when-should-you-branch/2107672#2107672, while being able at all time to merge back your code to another "main" line of development because you would do so:
  • 首先在您自己的存储库中进行本地操作，而不打扰任何人
  • 然后在远程服务器上，将合并结果推送到中央存储库上。