我知道 1000 多个类似的话题。我在 SO 中至少阅读了 5 个线程但是为什么我仍然不相信 DVCS？
我只有以下问题（请注意，我自私地只担心 Java 项目）
投我！
我一直在你现在所处的位置，对分布式版本控制的使用持怀疑态度。我读过所有的文章并且知道理论论据，但我并不相信。
直到，有一天，我输入git init并突然发现自己在一个 git 存储库中。
我建议你也这样做——简单地尝试一下。从一个小的爱好项目开始，只是为了掌握它。然后决定它是否值得用于更大的东西。
如果您的硬盘默默地开始破坏数据，那么您该死的很想知道它。Git 获取您提交的所有内容的 SHA1 哈希值。您有 1 个带有 SVN 的中央存储库，如果它的位被有故障的 HDD 控制器静默修改，您将不会知道它，直到为时已晚。
而且由于您有 1 个中央仓库，因此您只是炸毁了唯一的生命线。
使用 git，每个人都有一个相同的 repo，完整的更改历史记录，并且由于其完整图像的 SHA1，其内容可以完全信任。因此，如果您备份 HEAD 的 20 字节 SHA1，您可以确定当您从某个不受信任的镜像克隆时，您丢失的存储库完全相同！
当您使用集中式存储库时，所有分支都在那里供全世界查看。你不能建立私人分支机构。您必须创建一些尚未与其他全局名称冲突的分支。
“
test123——该死，已经有一个了test123。让我们试试test124。”
每个人都必须看到所有这些名称愚蠢的分支。你必须屈服于公司的政策，可能会遵循“除非你真的需要，否则不要建立分支机构”，这会阻碍你使用 git 获得的很多自由。
与提交相同。当你提交时，你最好确保你的代码能正常工作。否则你会破坏构建。没有中间提交。因为他们都去中央回购。
有了 git，你就没有这些废话了。分支并在本地提交所有你想要的。当您准备好向世界其他地方公开您的更改时，您可以要求他们从您那里提取，或者将其推送到某个“主要”git repo。
由于您的 repo 是本地的，所有 VCS 操作都很快，不需要往返和从中央服务器传输！git log不必通过网络查找更改历史记录。SVN 可以。与所有其他命令相同，因为所有重要的东西都存储在一个位置！
观看Linus关于 SVN 的这些和其他好处的演讲。
我是一名Mercurial开发人员，曾担任 Mercurial 顾问。所以我觉得你的问题很有趣，希望我能回答：
- 在本地提交有什么好处或价值？[...]
您是正确的，IDE 现在可以跟踪本地更改，而不仅仅是简单的撤消/重做。但是，这些文件快照和完整的版本控制系统在功能上仍然存在差距。
本地提交使您可以选择在提交“故事”以供审核之前在本地准备“故事”。我经常处理一些涉及 2-5 次提交的更改。在我提交 4 之后，我可能会返回并稍微修改提交 2（也许我在提交 4 之后在提交 2 中看到了一个错误）。这样我不仅会处理最新的代码，还会处理最后几次提交。当一切都在本地时，这是微不足道的，但如果您需要与中央服务器同步，则变得更加棘手。
- 如果我的硬盘崩溃了怎么办？[...] 那么与签入中央仓库相比，它有多酷呢？
一点都不酷！:-)
但是，即使使用中央存储库，您仍然需要担心工作副本中未提交的数据。因此，我认为无论如何你都应该有一个备份解决方案。
根据我的经验，人们通常在使用集中式系统的工作副本中存放大量未提交的数据。客户告诉我他们如何试图说服开发人员每周至少提交一次。
这些更改通常未提交，因为：
他们还没有真正完成。代码中可能有调试打印语句，可能有不完整的函数等。
提交将进入trunk，这对于集中式系统是危险的，因为它会影响其他所有人。
提交将要求您首先与中央存储库合并。如果您知道对代码进行了其他冲突更改，那么该合并可能会令人生畏。合并可能很烦人，因为您可能还没有完成所有更改，并且您更喜欢从已知良好的状态开始工作。
当您必须与过载的中央服务器通信时，提交可能会很慢。如果您在离岸位置，则提交速度会更慢。
如果您认为上述不是集中式版本控制与分布式版本控制的问题，那么您是绝对正确的。使用 CVCS，人们可以在不同的分支中工作，因此可以轻松避免上述 2 和 3。使用单独的一次性分支，我也可以根据需要提交尽可能多的内容，因为我可以创建另一个分支，在其中提交更完善的更改（解决 1）。但是，提交仍然可能很慢，因此 4 仍然可以应用。
使用 DVCS 的人通常会将他们的“本地”提交推送到远程服务器，作为穷人的备份解决方案。他们不会推送到团队其他成员正在工作的主服务器，而是推送到另一个（可能是私有的）服务器。这样他们就可以独立工作，并且仍然保留异地备份。
- 离线或在飞机上工作。[...]
是的，我也不喜欢这种论点。我在 99% 的时间里都有良好的互联网连接，而且飞得不够多，这不是一个问题 :-)
然而，真正的论据不是你离线，而是你可以假装离线。更准确地说，您可以独立工作，而无需立即将更改发送到中央存储库。
DVCS 工具是围绕人们可能离线工作的想法而设计的。这有许多重要的后果：
合并分支成为一件很自然的事情。当人们可以并行工作时，提交图中自然会出现分叉。因此，这些工具必须非常擅长合并分支。像SVN这样的工具不太擅长合并！
Git、Mercurial 和其他 DVCS 工具合并得更好，因为它们在这方面进行了更多测试，而不是直接因为它们是分布式的。
更大的灵活性。使用 DVCS，您可以自由地在任意存储库之间推送/拉取更改。我会经常在我的家庭和工作计算机之间进行推/拉，而不使用任何真正的中央服务器。当事情准备好发布时，我会将它们推送到像 Bitbucket 这样的地方。
多站点同步不再是“企业功能”，而是内置功能。因此，如果您有一个离岸位置，他们可以设置一个本地中心存储库并在他们之间使用它。然后，您可以每天或在适合您的时候同步本地集线器的小时数。hg pull这只需要一个运行或git fetch定期运行的 cronjob 。
更好的可扩展性，因为更多的逻辑在客户端。这意味着中央服务器上的维护更少，客户端工具更强大。
使用 DVCS，我希望能够通过代码的修订（不仅仅是提交消息）进行关键字搜索。使用集中式工具，您通常需要设置额外的索引工具。
DVCS 对我来说非常有趣，因为它：
为源代码控制过程添加了一个全新的维度：发布。
您不仅有一个合并工作流程，您还有一个发布工作流程（您将向哪个存储库推送/拉取），这可能有很多含义：
带来了一种生产/使用修订的新方法：
这意味着您不依赖于其他人将他们的工作交付给中央存储库，而是您可以与不同的参与者及其存储库建立更直接的关系。
您关于 IDE 为您进行跟踪的核心论点是错误的。除了无限的撤消级别之外，大多数 IDE 实际上没有任何此类功能。想想分支、合并、恢复、提交消息（日志）等等，我敢打赌，即使你提到的 IDE 也不够完善。特别是我怀疑它会跟踪你的提交——很可能是在你工作的几个不同的分支上——并在你上线后正确地将它们推送到存储库。
如果您的 IDE 确实做到了所有这些，我实际上将它本身称为分布式版本控制系统。
最后，如果中央存储库因任何原因而死机（您的服务提供商破产、发生火灾、黑客破坏了它……），您将在最近提取存储库的每台机器上进行完整备份。
编辑：您可以像使用集中式存储库一样使用 DVCS，我什至建议至少对中小型项目这样做。拥有一个始终在线的中央“权威”存储库可以简化很多事情。当那台机器崩溃时，您可以暂时切换到其他机器之一，直到服务器得到修复。
如果您没有看到本地历史或本地构建的价值，那么我不确定任何数量的问答是否会改变您的想法。
IDE 的历史功能有限且笨拙。它们与完整的功能完全不同。
如何使用这些东西的一个很好的例子是在各种 Apache 项目中。我可以将 git 存储库同步到 Apache svn 存储库。然后我可以在自己的私人分支机构工作一周。我可以从 repo 中向下合并更改。我可以报告我的变化，零售或批发。完成后，我可以将它们打包为一个提交。
有趣的问题。
我不是一个经验丰富的 DVCS 用户，但我有限的接触让我感觉非常积极。
我喜欢能够两步提交。这适合我。
浮现在脑海中的一些优点：
更好的合并支持。Branch-Merge 感觉更像是 DVCS 中的一等公民，而根据我对集中式解决方案的经验，我发现它既痛苦又棘手。合并跟踪现在可以在 svn 中使用，但它仍然很慢而且很麻烦。
大型团队。DVCS 不仅适用于单用户提交。您可以在回馈到主存储库（或不回馈）之前在团队之间推送和拉取提交。这对于某些类型的协作来说是无价的。
在开发实验性功能时，经常提交是有意义的，但仅限于短期。我不想总是分支主代码库，所以能够播放和重新录制很高兴。同样，我可以看到它在使用持续集成时很有用。如果我在重构工作上工作了几天，我可能会在不可接受的时间范围内中断构建，但我仍然想跟踪我的更改。
请注意，我的 DVCS 经验更多是使用 Mercurial 而不是使用 Git。来自 CVS/SVN 背景，我发现使用 Mercurial (Hg) 的学习曲线要容易得多。最近添加的对 Mercurial 的 Google 代码支持也是一个福音。...我什至会说，我对 Git 的最初反应是负面的，但更多的是从可用性的角度来看，而不是与 DVCS 有任何关系
我不会在这里卖任何东西。
• 本地承诺的优势或价值是什么？什么？真的吗？所有现代 IDE 都允许您跟踪您的更改？如果需要，您可以恢复特定更改。此外，它们还具有在 IDE 级别标记您的更改/版本的功能！？
唯一真正的优势是您不需要连接到主中央存储库。有人可以说 Git 的好处是开发人员可以在本地提交，准备大量的补丁组合，然后将它们拉到有福的中央仓库，但 IMO 这很无趣。开发人员可以使用 Subversion 存储库中的私有搁置或分支来处理他的任务，然后将其与主线（例如 /trunk）或其他分支合并。
对我来说，主要的缺点是我必须在我的机器上下载并存储整个 Git 存储库。对于一个历史悠久的大型项目，它变得很痛苦并且占用太多空间。
集中化的另一个缺点是Git 在技术上无法跟踪重命名或复制操作。它只是试图根据文件的内容猜测文件是否被重命名或复制。这导致了这样有趣的情况：svn to git migration保留复制文件的历史（Guy在问为什么在SVN>Git迁移之后文件的历史丢失了，）。
• 如果我的硬盘崩溃了怎么办？我的本地存储库去了哪里？（那么与签入中央仓库相比，它有多酷？）
使用 Git，如果您的本地存储设备（HDD、SSD 等）崩溃，并且它的更改没有被拉取或推送到受祝福的 Git 存储库，那么您就不走运了。您刚刚浪费了时间和代码。除此之外，本地 Git 存储库的硬盘崩溃可能会停止开发过程一段时间：Linus Torvald 的 SSD 损坏，停止 Linux 内核开发。
使用 SVN 等集中式源代码控制，您只能丢失最后一次提交，因为您的所有工作都已提交到中央存储库的分支、私有搁置甚至主干。显然，您应该确保为您的中央存储库实施灾难恢复和备份。
• Ok Linus Torvalds 将他的生命献给了 Git，并且憎恨其他一切。这足以盲目地歌颂吗？与我的中型项目中的离岸开发商相比，Linus 生活在不同的世界？
对于过去使用 BitKeeper 的 Linux Kernel 这样的项目，Git 是最好的源代码控制系统！但我想说 Git 并不适合所有人。
做出明智的选择！
很可能，没有人会在这里卖给你任何东西。如果您需要 git 的功能，只需git init. 如果它不适合你，那就不要。
如果您还不知道 git 功能，git vs请在 Google 搜索中输入（注意结尾空格），然后查看自动完成的结果。
在需要 Netbeans 功能之前，我更喜欢记事本而不是 IDE。似乎这里的情况是一样的。
如您所知，有很多成功的项目根本没有使用 VCS。
PS。销售 git 违反了它的许可证！;)