10

分布式修订控制系统的优点和缺点是什么？

如果您对Git、Mercurial、Plastic SCM等分布式系统有任何经验， 请分享您的经验。告诉我们什么工作得很好以及哪里出现了问题。

我特别有兴趣了解分布式系统在传统、商业、非开源项目中的使用，但也欢迎有关其他用途的回答。

4

4 回答 4

6

sebasgo 所指的问题确实有很多很好的答案，但还是让我告诉你我的个人经历吧。我与分散在美国各地的少数其他人一起工作，这些人基本上是私人咨询工作。客户的规模各不相同，但我们的团队很小，而且我们的工作速度相当快。代码是商业的，但在我们完成后归客户所有。

我们使用 Mercurial，但具体工具不如使用分布式版本控制而不是集中式的一般工作流程重要。根据我的经验，我不想再没有提高生产力的两大优势：

  1. 首先也是最重要的：分支和合并很容易。这是分布式的副作用，不是严格的要求，但它对 DVCS 至关重要，我发现它对我的工作至关重要。我们每个人都可以自由地分支我们需要处理的每一个功能，让它在沙箱中工作（不受我们共享存储库的干扰），当我们准备好时将其合并回来。“跟上”其他人的变化是就像偶尔合并一样简单，如果目前处理解决冲突的工作量太大，可以选择放弃合并并继续。我们可以抓取特定的更改并将它们放在一个测试分支中，如果我们喜欢它们就保留结果，如果我们不喜欢它们就扔掉它们。这种尝试、分享并只保留最佳结果的能力是一种严肃的益处。正如我所说，在这一点上，我不能舒适地工作。
  2. 离线工作。除非您不在通常的环境中工作，否则这听起来没什么大不了的。我可以去度假，旅行，或者停电，或者只是想在美好的一天把我的笔记本电脑带到外面，继续工作。能够起床走走而无需停止工作或失去检查工作的能力的心理益处是非常真实的。

除了那些适用于我所有项目的影响之外，与工作相关的而不是与工作相关的，还有一个特定于我们特定安排的好处，它与您关于商业用途的问题有关，这是出乎意料的：客户实际上可以处理代码。他们可以拍摄快照，进行本地更改，或者将修复发送回给我们，或者将调整后的代码保留用于特定目的。这有助于让他们参与进来，不会与他们想要的东西太不同步，并允许他们在不破坏任何东西的情况下进行调整（除非他们准备好，否则我们不会合并他们的更改——相同的规则我们自己申请。）

我们没有太多的抱怨。这需要一些时间来适应，尽管 Mercurial 的命令集与 Subversion（我们曾经使用过的）足够接近，所以我们没有遇到很多麻烦。即使是偶尔的麻烦，比如不小心签入了不应该签入的二进制文件或文件，我们也可以绕过，因为我们可以在没有这些更改的情况下重新创建一个存储库，并在需要时替换我们的主要存储库。这不能很好地扩展到一大群人，但对于一个 3-4 人的小型团队来说效果很好。

我能想到的一个负面因素实际上是一个问题，是能够轻松分支的副作用：您可能有足够多的待处理工作以至于您忘记了它。这有点类似于有许多书面文件的草稿：传递足够多的副本，而您不记得哪个副本有您想要的更改。这不是该工具的直接缺陷，如果有的话，它使将不同的工作重新组合在一起比合并能力较差的工具更容易。但这是一个危险。我知道管理它的唯一方法是严格编写有用的提交日志、有用的分支描述，并且不要试图一次保留太多未完成的任务。换句话说，即使是一个非常好的工作流程仍然是一个工作流程，需要引起注意，否则就会失控。

我对 Mercurial（我真的希望命名分支支持更容易一点）和 Git（我真的希望命令集更直观，即使是现在）有特别的问题，但他们抱怨的是随之而来的角落问题非常熟悉。如果这些工具没有突破我认为 VCS 可以做的事情远远超出我开始使用它们之前所知道的事情，那么它们甚至不可能实现。

于 2009-07-25T05:09:25.497 回答
3

阅读有关 stackoverflow 的这个问题，了解有关 GIT 与 SVN 以及中央与分布式系统的一般信息。

于 2009-07-22T21:18:34.960 回答
2

我没有尝试过其他分布式系统，所以无法评论它们。但是让我恼火的是 Git 没有办法只克隆存储库的一部分。最后我检查了一下，它也缺少类似于 svn:externals 的东西。我发现 svn externals 经常在公司内部用于从其他存储库中检出库等。

于 2009-07-22T21:07:42.647 回答
2

是的，为此检查stackoverflow问题。如果您想了解有关 Git 与其他版本控制系统的比较的更多信息，有一个很好的信息站点：为什么 Git 比 X 更好？

于 2009-07-22T22:35:32.063 回答