分布式版本控制系统和企业-好的组合？

我刚刚在一家大型银行公司中介绍了DVCS（在本例中为Git），其中Perforce，SVN或ClearCase是集中选择的VCS：我已经知道了挑战（请参阅我以前的回答“我们最终可以在公司软件中转向DVCS吗？SVN仍然是开发的“必备”吗？”）我在三个方面受到挑战：集中化：尽管分散化模型有其优点（并允许私有提交或在不使用网络的情况下访问完整的历史记录），但仍然需要有一套清晰的集中化仓库，作为所有开发人员的主要参考。身份验证：DVCS允许您以几乎任何人（作者“foo”，电子邮件“ \1ѭ”）的身份“注销”（提交）您的代码。您可以执行git config user.name foo或git config user.name whateverNameIFeelToHave，并在其中包含所有带有虚假名称的提交。这与大型企业使用的唯一的集中式“ Active Directory”用户引用不能很好地结合在一起。授权：默认情况下，您可以克隆，推送或拉入任何存储库，以及修改任何分支或任何目录。对于敏感项目，这可能是一个阻碍性的问题（银行界通常非常保护某些定价或量化算法，这些算法要求对数量有限的人员进行严格的读/写访问）答案（对于Git设置）是：集中化：已经为所有用户必须访问的任何存储库设置了唯一的服务器。备份已得到照顾（每天增量，每周完整）。已实施DRP（灾难恢复计划），并在另一个站点上使用了第二台服务器，并通过SRDF进行了实时数据复制。此设置本身独立于您所需的引用或工具的类型（DVCS或Nexus repo或主Hudson调度程序，或...）：必须将对发布至关重要的任何工具安装在服务器上与备份和灾难恢复。。身份验证：只有两种协议允许用户访问主存储库：基于ssh，具有公钥/私钥：对组织外部的用户（例如离岸开发）有用，对于Active Directory管理员不想创建的通用帐户非常有用（因为它将是一个“匿名”帐户）：一个真实的人必须负责该通用帐户，而该帐户就是拥有该帐户的人私钥基于https的，Apache通过LDAP设置对用户进行身份验证：这样，必须为这些存储库上的任何git操作提供实际登录名。 Git提供了它的智能http协议，它不仅允许通过pull（读），而且还允许通过push（写）。还通过“ 6”钩在Git级别上增强了身份验证部分，该钩确保您要推送到存储库的至少一个提交的“ committer name”等于通过shh或http协议检测到的用户名。换句话说，您需要正确设置git config user.name，否则您要推送到中央存储库的任何操作都会被拒绝。。授权：之前的两个设置（ssh或https）都已连接，以使用参数作为参数调用名为gitolite的同一组perl脚本：这两个协议检测到的实际用户名用户想要执行的git命令（克隆，推入或拉出） gitolite perl脚本将解析一个简单的文本文件，其中已设置了授权（对所有存储库，给定存储库内的分支，甚至对存储库内的目录具有读/写访问权限）。如果git命令所需的访问级别与该文件中定义的ACL不匹配，则该命令将被拒绝。上面介绍了我需要为Git设置实现的内容，但更重要的是，它列出了在具有唯一用户基础的大公司中使DVCS设置有意义的主要问题。然后，直到那时，DVCS（Git，Mercurial ...）才可以添加值，原因是：多个站点之间的数据交换：虽然这些用户都通过同一个Active Directory进行了身份验证，但是他们可以位于世界各地（我所服务的公司通常在两个或三个国家/地区的团队之间发展）。 DVCS自然是为了在这些分布式团队之间高效地交换数据而制作的。跨环境复制：负责认证/授权的设置允许克隆其他专用服务器上的存储库（用于集成测试，UAT测试，预生产和预部署目的）流程自动化：您可以轻松地克隆存储库，也可以在一个用户的工作站上本地使用，通过“受保护的提交”技术以及其他巧妙的用法进行单元测试，请参见：您曾经见过最聪明的源存储库使用？\“。简而言之，您可以推送到第二个本地仓库，负责：各种任务（单元测试或代码的静态分析）如果这些任务成功，则返回主仓库而您仍在第一个存储库中工作而不必等待这些任务的结果。。杀手级功能：随附的任何DVCS，主要是DVCS（曾经尝试使用SVN进行复杂的合并工作流程吗？还是使用ClearCase轻松地合并了6000个文件？）。仅此一项（合并）就意味着您可以真正利用分支的优势，同时能够始终将您的代码合并回另一条“ main”开发线，因为您可以这样做：首先在您自己的仓库中本地进行，而不会打扰任何人然后在远程服务器上，将合并的结果推送到中央存储库中。

秃拳割

在企业中，绝对可以使用分布式源模型，但是它确实取决于团队的结构。分布式源代码管理使您可以灵活地创建自己的工作流程。想象一下，如果有的话，请想象一个更大的团队，其中有一些较小的团队在单独的功能分支上工作。这些团队都可以拥有自己的中央存储库，并拥有自己的构建自动化/签入控制机制。他们可以在任何地方工作，并在需要时备份本地工作。然后，他们可以选择要在组之间共享的签到内容。他们可以有一个单独的集成商，在自己的计算机上工作，执行合并，而不会影响其他人。这些都是使用传统的集中式服务器可以实现的，但是正如@Brook所指出的，集中式模型必须进行扩展，而分布式模型已经被分片，因此不需要（或至少更少）来垂直扩展任何服务器。

闪票仇门韧

除了其他评论外，我会发现没有理由没有公司中央存储库。从技术上讲，它只是另一个存储库，但它是您从中运输产品的存储库。我使用VCS的另一种形式已有30多年了，我可以说改用Mercurial就像是一个城市男孩第一次呼吸乡村的空气。

拟僚疽刊剔

对于脱机或慢速网络，DSCS（通常）比集中式系统更好。它们往往会更快，这对于进行大量签入的开发人员（使用TDD）而言确实值得注意。集中式系统一开始就比较容易掌握，对于经验不足的开发人员来说可能是一个更好的选择。 DVCS使您可以创建许多小型分支并隔离新功能，同时仍可以对绿色编码风格进行红色格力重构检查。同样，它非常强大，但仅对相当精明的开发团队有吸引力。如果您处理不可合并的文件（例如数字资产和非文本文档（PDF和Word等）），则拥有一个用于支持排他锁的中央存储库就很有意义，因为它可以防止您陷入混乱并手动合并。我认为开发人员的数量或代码库的大小不会发挥太大的作用，这两个系统都显示出支持大型源代码树和提交者的数量。但是，对于大型代码库和项目，DVCS在快速创建分散的远程分支方面提供了很大的灵活性。您可以使用集中式系统来执行此操作，但是您需要更加仔细地考虑这是好是坏。简而言之，有一些技术方面需要考虑，但是您还应该考虑团队的成熟度以及他们围绕SCCS的当前流程。

献导外拘

至少在tfs 2013中，您确实能够与本地工作空间断开连接。分布式与集中式由企业定义，并且取决于开发中项目的需求和要求。对于企业项目，将工作流和文档与代码更改相关联的能力对于将业务需求和高阶元素与解决特定更改，错误或功能增加的特定代码更改相关联至关重要。工作流和代码存储库之间的这种连接将TFS与仅代码存储库的解决方案分开。对于某些需要更高级别的项目审核的地方，只有像TFS这样的产品才能满足更多的项目审核要求。可以在此处找到应用程序生命周期管理过程的概述。 http://msdn.microsoft.com/zh-CN/library/vstudio/fda2bad5(v=vs.110).aspx

屠创氓读叔

我们在企业环境中使用Git面临的最大问题是缺乏基于路径的读取访问控制。在Git的体系结构中（我会假设大多数DVCS），这是固有的，如果您对存储库具有读取权限，那么您将获得全部内容。但是有时项目会要求稀疏签出（例如，您想对源附近的敏感数据进行版本控制，或者想让第三方选择查看项目的一部分）。开箱即用，Git不提供任何权限-您必须编写自己的钩子。大多数受欢迎的回购管理器GithubEnterprise，Gitlab，Bitbucket提供基于分支的写限制。凹凸棒石可以提供更细的颗粒，从而提供基于路径（以及更多）的写限制。我听说过的唯一支持读访问权限的仓库管理器是Perforce Helix，它在perforce后端之上重新实现了git协议，但是我对此没有亲身经验。这是有前途的，但是我会担心它与“纯” git的兼容性如何。