我最近在一家大公司中使用商业集中控制版本控制系统，有大约100个不同的子系统用不同的操作系统和语言编写，我注意到有几个开发人员在他们的宠物项目上使用git或mercurial，但是没有对于他们的工作系统。我个人对git更熟悉，但是想知道他们“不”在企业中使用Git的原因是什么，除了已经做出选择的事实（我们的集中控制版本系统有很多问题，所以我可以不能说这很棒。
自从我写这篇文章以来，世界确实发生了变化。当时实际上不允许Git使用的公司现在使用Mercurial作为他们的首选系统
答案 0 :(得分：15)
我不同意企业害怕自由或改变缓慢的想法。这些可能是正确的，但是使用它们来消除企业空间中git的缓慢采用率忽略了企业的意义。此外，SVN非常受欢迎，而且它是免费的。
企业是关于集中化的。您希望所有开发人员遵循相同的过程，获得相同的代码等。
Eric Sink在这个问题上比我更有说服力：http://www.ericsink.com/articles/vcs_trends.html
答案 1 :(得分：12)
如果我不得不猜测，我会说这是因为企业一直对使用“免费”的东西持谨慎态度。主要是因为他们缺乏一个稳定的支持系统（一般来说，支持来自StackOverflow.com或论坛的开源形式），但也有一种普遍的心态，“你得到你付出的代价”。他们认为，如果不花费他们的许可费用，那么它在实际可用性方面必须是值得的。
当然，作为技术专家，我们知道这是一个负担。
答案 2 :(得分：8)
恕我直言，然后问题不是 GIT本身或分布式版本控制：问题是改变SCM并走向未知且可能对企业规则集“危险”的东西。这就是“抗体”发挥作用以防止任何重大变化的原因。
更具体地说，关于GIT，许多风险和威胁正在提供反对其采用的额外论据，与上述三点有关：
我在GIT之前多次看过“反身体”：
所有这些示例一直是突出企业级术语变化的正负的关键：评估风险，成本和收益......以及所有这些都清楚地记住谁是反身体，我们如何减轻它们，或“确保一条漂亮的小巷让它们用旧工具行走”。
经过大量的努力和努力，所有这些迁移最终都非常成功！我在大型企业中引入了GIT，例如英国和德国的Vodafone Group Services 。无论如何，在经历了痛苦和阻力之后，变化已经开始，并且效益已经显而易见，并且已经在效率，敏捷性和控制方面提供了显着的投资回报率。
在合规和支持方面，我看到积极帮助采用供应商协助的赞助。一些例子：
一般来说，改变是大型企业中最昂贵但更重要的任务，首先是从人们心态的角度来看。
让我知道您对Git和Enterprise Tools采用的看法！
Luca / @lucamilanesio
答案 3 :(得分：7)
有很多原因：
惯性：有很多人熟悉集中式系统。如果你不改变，你不必“重新培训”开发人员。
与其他工具的互动：企业环境对于持续集成，IDE，花哨的问题跟踪器等额外工具来说当然很重要。当然，与已经相对较新的git和hg相比，对已建立的集中式VCS的支持更多。
支持：当您购买商用VCS产品时，您不仅仅是购买该产品，而且购买时也会安心。
当然，我并不是说这些好的原因;他们只是让那些有能力做出这个决定的人有说服力。我认为值得克服惯性 - 它现在需要工作，但它会在以后得到回报。我认为外部工具在支持git方面越来越好，特别是开源软件 - 他们只需要插件。至于支持，我们都知道互联网上有很多不太正式的支持。
真的，所有这些都有一个共同的想法 - 自由软件哲学并不是企业开展业务的方式。购买产品很容易。你付钱，你得到你需要的。管理层不必担心。使用免费软件产品......好吧，它可能会好得多，但处理起来会更复杂。它不是一个盒子。
澄清：我使用“免费”这个词的方式与自由软件世界中的一样 - 免费，而不是啤酒。希望这句话最终能够深入到每个人的脑海中。请注意，我从来没有在这里处理成本问题 - 尽管我认为在git的情况下，一般来说它最终会比购买的解决方案便宜，尽管需要让每个人加快速度并确保它的成本适合你的其他过程。这不是一个干脆的问题，因为我认为git是未来的，所以没有把它放在子弹中。
答案 4 :(得分：5)
根据我的经验，这是对改变的恐惧。源代码管理是基础架构的核心部分，会影响所有开发人员。如果当前的系统不会伤害太多企业，IT实际上会对抗变革。
我经常听到的另一个原因是IDE集成还没有达到例如CVS或Subversion。虽然这个论点是正确的，但它正在变得越来越有问题。
答案 5 :(得分：4)
可以询问有关使用其他内容切换任何大型基础架构服务的同样问题。当有成百上千的人使用某种东西时，最好还是要破坏，或者新东西最好提供一些引人注目的功能。
考虑切换电子邮件系统。有人必须培训所有用户，传输所有消息，在最短的停机时间内完成切换并且不会丢失数据，然后说服管理层不会对业务运营造成重大干扰。
在您的具体示例中，将源控制系统转换为100个子系统，同时保留历史记录并重新培训所有开发人员，测试人员和发布工程师，而不影响他们的日常工作效率，这是一项艰巨的任务。现有系统必须真正损坏。
答案 6 :(得分：2)
Git是一个具有协作和共享态度的版本控制系统。实际上，您无法强制执行特定的访问和共享模式。如果使用git的人不想遵守您的规则，该工具对您没有多大帮助。
虽然我个人认为这种组织行为是愚蠢的，但我确信有人认为这是个好主意。也许你担心你的不守规矩的员工在错误的项目上工作，或者你迫切想要改变代码。
答案 7 :(得分：1)
“除了已经做出选择的事实”
这一部分的陈述实际上太重要了，无法忽视，因为它与任何特定工具的学习曲线相关联。例如，学习SVN需要一段时间，学习过程会以开发人员时间的形式花钱。根据我的经验，学习git需要更多的时间，并且在没有简化的界面的情况下变得更加复杂（gittortoise的持续开发不能承受）。加上Git有这么多工具，它的学习曲线实际上可以被认为更像是一个学习斜率。
越过曲线后的收益很大，但最初的要求是采用的障碍。
答案 8 :(得分：1)
除了Eric提到的缺乏集中控制和集成之外，企业采用的一个重要实际障碍是“易用性”。
如果您习惯于Subversion或PVCS等类似工具，那么Git（以及一般的DVCS）代表着一个重要的学习之路 - 无论是在概念层面还是在日常工作流程中。在我（有点厌倦）的经历中，许多企业开发人员往往不愿意投入精力学习新的工具或概念;我担心会破坏任何引入DVCS的尝试。
请证明我的错误
答案 9 :(得分：1)
以下是一些具体建议。 （阅读完整博客here）。
如果您对作品的单个，某些主副本有强制要求，请使用Subversion。你可以用Git做到这一点，只要没有漏洞。但是你不能用Subversion做任何其他事情（滑倒或没有），像萨班斯 - 奥克斯利法这样的“令人信服的要求”对于保证而不是可能性更快乐。
如果您计划保持同一产品的并行，大部分共享但永久性不同的行，请使用Git。一个常见的例子：也许你有一个为每个客户定制的大型产品。自定义是永久性的，通常不在代码行之间共享，但大多数代码对所有代码都是通用的。 Git就是针对这种情况而设计的（用Git术语，对公共核心的本地自定义，以及偶尔的功能或bug修复贡献备份树）。
这些都没有？拿你的选择，你可以使用任何一种工具。
答案 10 :(得分：-1)
部分困难不是由于系统而是由于工人的组织。
SVN易于理解和使用 但如果用于少数开发工作在一个分支（或头部）
，则会更好Git是一个好主意，但实施起来非常恶心 并且需要花费大量时间和精力做一些简单的事情，比如把你的该死的代码放进去！
我们还在等DECENT DVCS ...