似乎很多人都在阅读有关分布式版本控制的内容，并且隐含地理解为什么它对于开源开发来说是一件好事，许多分布式开发人员都是独立行事并且根据他们自己的选择而不是管理层的授权。但是从这种印象来看，许多人认为DVCS在开源环境中只有 是有用的。他们无法看到它如何帮助发布专有产品的组织，并且不会使其版本控制系统在外部可访问，或者它如何帮助单个开发人员。
如果企业选择使用分布式版本控制（如git，darcs或Mercurial）而不是集中版本控制（如CVS或Subversion），企业可以看到哪些好处？
答案 0 :(得分：11)
这个论点似乎向后退了。
鉴于集中式修订控制系统只是分布式系统的众多用例之一，应用这种限制如何使公司受益？
我从经验中知道，当p4服务器变慢或中断或者你离它太远时，使用它的每个人都必须停止工作。
人们喜欢把“飞机”这个论点当作一个稻草人，但我一直在那里真正重要的地方。在互操作事件或客户演示的现场，我们必须在网络支持有限的环境中构建现在，并且所有工作必须返回和我想成为当我犯错时能够恢复。
我听到的两个论点对我来说并不顺利：
1号只是愚蠢的。也许稍微努力来获得完整的历史记录（如果我不能，那么无论如何都没有修订控制系统），但是当谈到我们在这里讨论的那种恐惧时，我可以抓住最新版本，这也很危险。
第2号看起来似乎试图使用错误的工具来完成工作。我曾经从RCS用户那里获得反CVS参数，因为他们真的认为你应该每隔时间锁定每个文件，以防止两个人（我不知道）工作。
沟通是带外的。如果你有大的，不可合并的文件，我认为可以谈论它们。 IMO，很多有这个问题的人都不想要一个版本控制系统，而是一个快照文件系统（zfs，9fs，Drop Box等）。
总的来说，我不明白为什么人们甚至会问“我为什么要给开发人员提供更便宜，更快，更可靠，更强大的工具，并使他们更高效？”各种问题。
答案 1 :(得分：5)
首先，DVCS不会阻止集中式代码管理：您仍然可以将一个存储库设置为“参考”存储库，所有开发人员都可以将其从中拉出来。
因此，这里的好处（实际上是副作用）是通过数据复制进行自然备份，同时保持中央代码库。
但真正的好处来自项目间的交叉开发：即当你需要“来自其他团队，来自其他项目”的开发时，为了让你的工作继续前进：你可以轻松地将他们的工作拉到一起分支到您的存储库（通过跟踪它），而不必等待它们正式在中央存储库中发布它。
这意味着即使存储库仅在内部复制 （在公司内），您仍然可以获得DVCS的主要优势，即从本地和多样化的回购中轻松跟踪，提取和合并分支，同时拥有一个主要基地，可以在其余的开发生命周期中发布代码 （每个集成，认证，预生产测试只会从发布到中央存储库的代码中运行。）
人们还可以看到DVCS以这种方式管理一个自然的“清洁”过程（只有“有效” - 至少是单元测试 - 才能发布到中央仓库），历史更清晰（所有中间提交可以保留在本地存储库的主题分支中。）
答案 2 :(得分：5)
我同意VonC，但是想补充一点（至少在git中），创建新的分支是很容易的，我可以轻松地处理实验代码或原型，我不一定想与其他人共享存储库的用户。这有助于保持中央存储库的清洁（如果您使用它），我认为可以让开发人员尝试在他们冒险将实验代码放入中央存储库的系统中尝试的事情。
我还注意到，使用git在多个分支中工作效率更高，因为在分支之间交换很快，而且我不需要在单独的目录中一次检出多个分支。
答案 3 :(得分：3)
使用git，可以与传统的基于中央存储库的系统建立许多桥梁。
我发现git是svn的优秀客户端而不是svn本身。因此，如果公司坚持使用中央存储库系统，您仍然可以在维护中央存储库的同时获得git的个人利益。
答案 4 :(得分：1)
我注意到使用Mercurial的一件事是它改变了我的工作方式，甚至改变了我的工作站本地。每个副本都是完整的，独立的回购的想法有助于保留不同的副本与不同的工作，并将它们合并在一起或“共同”的回购。这很好，因为不同的东西的补丁集保持在一起，以及保持工作本身分开。这些东西可以在传统系统中以某种方式完成，但在Mercurial中它很自然。在组织工作流程方面提供更多灵活性还有其他不错的回报。
答案 5 :(得分：0)
我不明白为什么开源开发会更好。商业项目也有很多开发人员同时处理不同的事情。您的“管理层授权”是否告诉您要编辑哪些文件以及何时编辑？
答案 6 :(得分：0)
检查此处的优势......
http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git
http://www.ehow.com/info_12217814_git-commit-vs-push.html