对于实际上从不分布式的团队来说，分布式版本控制有什么优势？
远程工作时，我们的团队只能通过远程桌面进入我们的办公室电脑来访问我们的源代码，因此我们从来没有真正在离线模式下工作。与当前的集中式 Subversion 设置相比，像 Mercurial 或 Git 这样的分布式版本控制系统是否仍然给我们带来优势？如果有，它们是什么？有什么缺点或陷阱吗？我在很多地方读到，转向分布式版本控制需要改变思维。有人可以解释一下这方面需要改变什么吗？
When working remotely, our team only has access to our source code by remote desktop into our office PCs so we never really work in offline mode. Does a distributed version control system like Mercurial or Git still give us advantages over our current centralized Subversion set up? If so, what are they? Are there any drawbacks or pitfalls? I've read in numerous places that shifting to distributed version control requires a change in thinking. Can someone explain what needs to change in this regard?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正如 DVCS 和CVCS（集中式VCS），主要优点是：
最后一点需要最大的“思维改变”并且有点可怕（“我可以从任何存储库中提取？！”）
但是，一旦您意识到这些好处，您确实可以拥有更高效的开发周期，因为您能够监控（通过获取同行的提交）一些同事的开发。如果他们正在开发您需要的功能，您可以更快地开始集成它。
（使用 DVCS 需要记住的是，这不会阻止设置“中央”存储库，以供其他开发人员从中提取）
至于持续集成，而不是直接从存储库推送到负责的中央服务器CI，您可以推送到桌面上的本地存储库，该存储库将运行所有测试，然后自动将代码（如果“绿色”）推送到“中央”存储库。
它非常有效，您现在可以将“永远不会破坏构建”的代码推送到官方中央存储库，从而使您的 CI 服务器几乎毫无用处;)
As explained in the differences between DVCS and CVCS (Centralized VCS), the main advantages are:
That last point required the most "change in thinking" and is a bit scary ("I can pull from any repo?!")
But once you realize the benefits, you can really have more productive development cycles because you are able to monitor (by fetching commits from your peers) the development of some of your colleagues. If they are developing a function that you need, you can start integrating it sooner.
(The thing to remember with a DVCS is that is doesn't prevent the setup of a "central" repo, for other developers to pull from)
As for continuous integration, instead of pushing directly from your repo to a central server in charge of CI, you can push to a local repo on your desktop, which will run all the tests, before pushing automatically (if "green") the code to a "central" repo.
It is so effective that you can now push to the official central repo a code that "never breaks the build", rendering your CI server pretty much useless ;)
我推荐 HgInit 作为关于如何通过去中心化工具集改进 svn 的非常彻底的解释。它还将帮助您理解概念差异。
我想强调的重大改进之一是合并跟踪的概念。 Subversion 直到 1.5 版本才具备此功能，而且由于它处理修订和分支的方式不同，它可能永远不会像分散式工具那样好。没有人喜欢合并。不妨尽可能减少这种痛苦。另请参阅：为什么分支和合并在Mercurial 比 Subversion 更好？。
对我来说，从 subversion 切换过来时，思维上最大的变化是克服了历史是严格线性的、分支只不过是将代码复制到另一个目录的想法。请注意，在 Git 和 Mercurial 中，您不会签出存储库的子目录。您不会看到 'git checkout http://github.com/project/branches/v2。 0' 或任何东西。 Eric Sink 对历史存储方式的差异做了很好的解释。我建议看一下。
I would recommend HgInit as a very thorough explanation of just how svn is improved upon by a decentralized toolset. It will also help you to understand the conceptual differences.
One of the big improvements I'd like to emphasize is the notion of merge tracking. Subversion didn't have this feature at all until 1.5, and with the difference in the way it treats revisions and branches, it will probably never be as good as the decentralized tools can be. Nobody likes merges. Might as well reduce as much of that pain as you can. Also see: Why is branching and merging easier in Mercurial than in Subversion?.
The biggest change in thinking for me when making the switch from subversion was getting over the idea that history is strictly linear, and branching is nothing but copying code to another directory. Note that in Git and Mercurial, you don't checkout a subdirectory of the repository. You won't see 'git checkout http://github.com/project/branches/v2.0' or anything. Eric Sink wrote a really good explanation of the difference in the way the history is stored. I recommend taking a look.
开发机器可能彼此相邻，但源代码仍然分布在它们之间。机器在物理上非常接近对于管理不同开发人员所做的源代码更改实际上并不重要。
The development machines might stand next to each other, but the source code is still distributed between them. That the machines are in close physical proximity really doesn't matter for managing source code changes made by different developers.