业务为什么要使用分布式版本控制？

Question

似乎很多人读过关于分布式版本控制的文章，并且含蓄地理解了为什么它对开放源码开发是一件好事，因为许多分布式开发人员都是按照自己的选择独立行事，而不是按照管理层的要求行事。但是，从这种印象中，许多人形成了这样的想法: DVCS只在开放源码环境中才有用；他们看不出它如何帮助一个发布专有产品的组织，也看不出它的版本控制系统在外部是可访问的，或者它如何帮助单个开发人员。

如果企业选择使用分布式版本控制(如git、darcs或Mercurial )而不是集中式版本控制(如CVS或Subversion )，那么它可以看到哪些好处？

Answer 1

在我看来，争论似乎是相反的。

考虑到集中式修订控制系统只是分布式系统的许多用例之一，那么应用这种限制对公司有什么好处呢？

我从经验中了解到，当p4服务器变慢或中断，或者您离它太远或其他什么的时候，使用它的每个人都必须停止工作。

人们喜欢把“飞机”的争论当作一种“稻草”，但我去过真正重要的地方。在现场的互操作活动或客户演示中，我们现在必须在有限的网络支持环境中构建一些东西，所有这些工作都必须回来，当我犯错误时，我希望能够恢复。

我听到的两个论点对我来说不太好：

run.

• locking

1. 不能接受所有的代码和

一号太蠢了。也许要获得完整的历史记录稍微困难一些(如果我做不到，无论如何也没有一个修订控制系统)，但是当涉及到我们在这里谈论的那种恐惧时，我可以抓住最新的修订版，这也同样危险。

第二条似乎真的是试图使用错误的工具来完成这项工作。我曾经从RCS用户那里获得反CVS参数，因为他们真的认为每次都应该锁定每个文件，以防止两个人(我不知道)工作。

通讯已经超出了控制范围。如果你有大的、不可合并的文件，我认为谈论它们是可以的。IMO，许多有这个问题的人不想要一个修改控制系统，而是一个快照文件系统(zfs、9fs、Drop等等)。

但总的来说，我不明白为什么人们会问：“为什么我要给我的开发人员提供更便宜、更快、更可靠、更健壮、更高效的工具呢？”各种各样的问题。

Answer 2

首先，DVCS并不阻止集中式代码管理:您仍然可以将一个存储库设置为“引用”库，所有开发人员都可以从它中提取。

因此，这里的好处(实际上是副作用)是通过数据复制进行自然备份，同时维护中央代码库。

但真正的好处来自于项目间的交叉开发:即，当您需要“来自另一个团队，来自另一个项目”的开发时，才能继续您的工作:您可以轻松地将其中一个工作分支拉到您的存储库中(通过跟踪)，而不必等待它们在中央存储库中正式发布它。

这意味着，即使存储库仅在内部复制(在公司内部)，您仍然可以获得DVCS的主要优势，即可以轻松地跟踪、提取和合并本地和各种repos中的分支，同时在开发生命周期的其余部分有一个发布代码的主要基础。

(每一个集成、同源、预生成测试都只能从发布到中央存储库的代码中运行)。

我们还可以看到，通过这样的方式管理DVCS，一个自然的“清理”过程(只有“有效的”(例如，经过单元测试的)才会被发布到中央回购系统中)，具有更清晰的历史记录(所有中间提交都可以保留在本地存储库的主题分支中)。

Answer 3

我同意VonC的观点，但我想补充一点(至少在git中)，创建新的分支非常简单，我可以轻松地处理实验代码或原型，而这些代码或原型我不一定希望与存储库的其他用户共享。这有助于保持中央存储库的整洁(如果您使用的话)，我认为可以让开发人员自由尝试他们可能不会尝试的东西，在这样一个系统中，您可能会冒险将实验代码放入中央存储库。

我还注意到，使用git在多个分支中工作的效率要高得多，因为在分支之间进行交换非常快速，而且不需要在单独的目录中同时签出多个分支。