对于实际上从未分发过的团队，分布式版本控制有哪些优势？

Question

远程工作时，我们的团队只能通过远程桌面访问我们的办公室PC中的源代码，因此我们永远不会真正在离线模式下工作。像Mercurial或Git这样的分布式版本控制系统是否仍然优于我们当前的集中式Subversion设置？如果是这样，他们是什么？有任何缺点或陷阱吗？我已经在很多地方读过，转向分布式版本控制需要改变思路。有人可以解释在这方面需要改变什么吗？

Answer 1

如differences between DVCS and CVCS（集中式VCS）中所述，主要优点是：

• 本地提交（您可以在私有分支中更频繁地提交，然后清理您想要推送到其他回购的历史记录）
• publication process（你从多个回购，或快速建立的中间回购推送到，在那里你可以做中间任务，如持续集成测试）

最后一点需要最大的“改变思维”并且有点可怕（“我可以从任何回购中获取？！”） 但是一旦你意识到这些好处，你就可以真正拥有更高效的开发周期，因为你能够监控（通过从同行那里获取提交）一些同事的开发。如果他们正在开发您需要的功能，您可以尽快开始集成它 （用DVCS记住的事情是，这并不妨碍设置“中央”仓库，以供其他开发人员使用）

对于持续集成，您可以直接从您的仓库推送到负责CI的中央服务器，而不是直接推送到桌面上的本地仓库，该仓库将运行所有测试，之后自动（如果“绿色”）将代码推送到“中央”仓库 它是如此有效，您现在可以向官方中央仓库推送一个“永不破坏构建”的代码，使您的CI服务器几乎无用;）

Answer 2

我建议HgInit作为对分散工具集如何改进svn的非常详尽的解释。它还可以帮助您理解概念上的差异。

我想强调的一个重大改进是合并跟踪的概念。 Subversion在1.5之前根本没有这个功能，并且由于它对待修订和分支的方式不同，它可能永远不会像分散的工具那样好。没有人喜欢合并。不妨减少尽可能多的疼痛。另请参阅：Why is branching and merging easier in Mercurial than in Subversion?。

当我从subversion切换时，对我的思考中最大的改变是克服历史严格线性的想法，并且分支只不过是将代码复制到另一个目录。请注意，在Git和Mercurial中，您不会签出存储库的子目录。你不会看到'git checkout http://github.com/project/branches/v2.0'或任何东西。 Eric Sink写了一篇关于历史存储方式差异的非常好的解释。我推荐taking a look。

Answer 3

开发机器可能彼此相邻，但源代码仍然在它们之间分配。对于管理不同开发人员所做的源代码更改而言，这些机器在物理上非常接近并不重要。