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

Closed. This question is opinion-based。它当前不接受答案。












想改善这个问题吗？更新问题，以便editing this post用事实和引用来回答。

2年前关闭。



Improve this question




我可以看到为什么分布式源代码控制系统(DVCS-Mercurial)对于开源项目有意义。

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

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

最佳答案

我刚刚在一家大型银行公司中引入了DVCS(在这种情况下为Git)，其中Perforce，SVN或ClearCase是集中的VCS选择:
我已经知道了挑战(请参阅前面的答案“Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?”)

我在三个方面受到挑战:

集中化:尽管分散模型有其优点(并允许私有(private)提交或在不使用网络的情况下工作，但可以访问完整的历史记录)，但仍然需要一组清晰的集中式回购协议(protocol)，以作为主要的引用所有开发人员。

身份验证:DVCS允许您以几乎任何人(作者“foo”，电子邮件“[e-mail]”)的身份“签署”(提交)代码。
您可以执行git config user.name foo或git config user.name whateverNameIFeelToHave，并在其中添加所有带有假名称的提交。
这与大型企业使用的唯一的集中式“Active Directory”用户引用并不一致。

授权:默认情况下，您可以克隆，推送或拉到任何存储库，以及修改任何分支或任何目录。
对于敏感项目，这可能是一个阻碍性的问题(银行界通常对某些定价或量化算法具有很好的保护作用，这要求对数量有限的人员进行严格的读/写访问)

答案(对于Git设置)是:

集中化:已为必须由所有用户访问的任何存储库设置了唯一的服务器。
备份已得到照顾(每天增量，每周完整)。
已实现DRP(灾难恢复计划)，在另一个站点上使用了第二台服务器，并通过SRDF进行了实时数据复制。
此设置本身独立于您所需的引用或工具的类型(DVCS或Nexus repo或主Hudson调度程序，或...):必须将对发布至关重要的任何工具安装在服务器上与备份和灾难恢复。

。

身份验证:只有两种协议(protocol)允许用户访问主存储库:

基于

ssh，具有公钥/私钥:

对组织外部的用户(如离岸开发)很有用，

，对于Active Directory管理器不想创建的通用帐户很有用(因为它将是一个“匿名”帐户):一个真实的人必须负责该通用帐户，并且该人将是拥有私钥的人

基于

基于https的，Apache通过LDAP设置对用户进行身份验证:这样，必须为这些存储库上的任何git操作提供实际的登录名。
Git提供了它的smart http protocol，它不仅允许通过http读取pull，还允许通过http写入push。

还通过 post-receive 钩子(Hook)在Git级别上增强了身份验证部分，该钩子(Hook)确保至少您要推送到存储库的提交中的的“提交者名称”等于通过shh或h​​ttp检测到的用户名。协议(protocol)。
换句话说，您需要正确设置git config user.name，否则您要推送到中央存储库的任何操作都会被拒绝。

。

授权:之前的两个设置(ssh或https)都被连接为调用同一组perl脚本，名称为 gitolite ，并带有以下参数:

这两个协议(protocol)检测到的实际用户名

用户想要执行的git命令(克隆，推入或拉出)

已设置授权(所有存储库，给定存储库内的分支，甚至存储库内的目录的读/写访问权限)的gitolite perl script will parse a simple text file。
如果git命令要求的访问级别与该文件中定义的ACL不匹配，则该命令将被拒绝。

上面介绍了我需要为Git设置实现的内容，但更重要的是，它列出了在具有唯一用户基础的大公司中使DVCS设置有意义的主要问题。

然后，直到那时，DVCS(Git，Mercurial等)可以添加值，原因是:

多个站点之间的数据交换:虽然这些用户都通过同一个Active Directory进行了身份验证，但是它们可以位于世界各地(我工作的公司通常在两个或三个国家的团队之间发展)。 DVCS自然是为了在这些分布式团队之间高效地交换数据而制作的。

跨环境复制:负责认证/授权的设置允许克隆其他专用服务器上的存储库(用于集成测试，UAT测试，预生产和预部署目的)

流程自动化:克隆存储库的简便性也可以在一个用户的工作站上本地使用，使用“ protected 提交”技术和其他巧妙的用法进行单元测试，请参见:What is the cleverest use of source repository that you have ever seen?。
简而言之，您可以推送到第二个本地仓库，负责:

各种任务(单元测试或代码的静态分析)

如果这些任务成功完成，则

推回主存储库
当您仍在第一个存储库中工作时，无需等待这些任务的结果即可使用

。

。

killer features :那些随附的任何DVCS，主要是合并(是否曾尝试使用SVN进行复杂的合并工作流程？还是用ClearCase缓慢地合并了6000个文件？)。
仅此一项(合并)就意味着您可以真正利用branching，同时能够始终将您的代码合并回另一个“主”开发线，因为您可以这样做:

首先在您自己的存储库中本地进行，而不会打扰

然后在远程服务器上，将合并的结果推送到中央存储库中。