我知道有数千个相似的话题浮出水面。我在这里读了至少5个线程但是为什么我仍然不相信DVCS？
我只有以下问题（请注意，我只是自私地担心Java项目）
推销我！
答案 0 :(得分：14)
我一直在你现在的位置，对分布式版本控制的使用持怀疑态度。我读过所有的文章，知道理论上的论点，但我不相信。
直到有一天，我输入git init并突然发现自己进入了一个git存储库。
我建议你这样做 - 只需尝试一下。从一个小的业余爱好项目开始，只是为了掌握它。然后决定是否值得使用更大的东西。
答案 1 :(得分：13)
如果您的硬盘默默地开始破坏数据，那么你真的很想知道它。 Git采用你提交的所有内容的SHA1哈希值。你有一个带SVN的中央仓库，如果它的位被一个故障的硬盘控制器静默修改，你就不会知道它，直到为时已晚。
由于你有1个中央回购，你只是吹了你唯一的生命线。
使用git，每个人都有一个相同的回购，包含更改历史记录，并且由于SHA1的完整图像，其内容可以完全受信任。因此，如果你备份你的HEAD的20字节SHA1，你可以确定当你从一些不受信任的镜像克隆时，你有完全相同的repo你丢失了！
当您使用集中式仓库时，所有分支都可供全世界查看。你不能建立私人分支机构。您必须创建一些尚未与其他全局名称冲突的分支。
“
test123- 该死的，已经有了test123。让我们试试test124。“
每个人都必须以愚蠢的名字看待所有这些分支。你必须屈服于公司政策，这可能与“除非你真的需要”之后不要分支，这会阻止你用git获得很多自由。
与提交相同。当你提交时，你最好确实确保你的代码有效。否则你打破了构建。没有中间提交。因为他们都去了中央回购。
使用git，你没有任何废话。在本地分支和提交所有你想要的。当你准备将你的变化暴露给世界其他地方时，你会要求他们从你那里撤走，或者你把它推到一些“主要”的git仓库。
由于您的仓库是本地的，所有VCS操作都是快速，并且不需要往返行程并从中央服务器转移！ git log无需通过网络查找更改历史记录。 SVN呢。与所有其他命令相同，因为所有重要的东西都存储在一个位置！
观看Linus' talk以获取有关SVN的这些和其他好处。
答案 2 :(得分：10)
我是Mercurial开发人员，曾担任Mercurial顾问。所以我发现你的问题非常有趣，希望我回答：
- 本地承诺的优势或价值是什么？ [...]
如今，IDE可以跟踪简单的撤消/重做以外的本地更改。但是，这些文件快照与完整版本控制系统之间的功能仍然存在差距。
本地提交让您可以选择准备您的故事＆＃34;在您提交以供审核之前在本地。我经常处理涉及2-5次提交的一些更改。在我提交4之后，我可能会稍微修改提交2（也许我在提交4之后在提交2中看到了错误）。这样我就不仅可以使用最新的代码，还可以使用最后几次提交。当一切都是本地的时，这很容易实现，但如果你需要与中央服务器同步，它就会变得更加棘手。
- 如果我的硬盘坏了怎么办？ [...]那么与登记中央仓库相比，它有何凉爽？
一点也不酷！ ： - ）
但是，即使使用中央仓库，您仍然需要担心工作副本中的未提交数据。因此，我会声称你应该有一个备份解决方案。
根据我的经验，人们通常会使用集中式系统在其工作副本中放置更大量的未提交数据。客户告诉我他们是如何试图说服开发人员每周至少一次。
由于以下原因，这些更改通常不会引起注意：
他们并没有真正完成。代码中可能有调试打印语句，可能有不完整的函数等。
提交将进入trunk，并且危险使用集中式系统，因为它会影响其他所有人。
提交将要求您首先合并与中央存储库。如果您知道代码中存在其他相互冲突的更改，那么合并可能会令人生畏。合并可能只是令人讨厌，因为您可能并未完成所有更改，而您更愿意从已知良好状态开展工作。
当您需要与过载的中央服务器通信时，提交可能会很慢。如果你在离岸地点，提交的速度会更慢。
如果你认为上述并不是集中式与分布式版本控制的问题，那么绝对正确。使用CVCS，人们可以在不同的分支机构工作，因此可以避免上面的2和3。有了一个单独的抛弃分支，我也可以尽可能多地提交，因为我可以创建另一个分支，我提交更多优化的变更（解决1）。但是，提交仍然可能很慢，所以4仍然适用。
使用DVCS的人通常会推送他们的本地＆＃34;无论如何，提交到远程服务器作为穷人的备份解决方案。他们不会推送到团队其他成员正在工作的主服务器，而是推送到另一个（可能是私有的）服务器。这样他们就可以孤立地工作，并且仍然可以进行异地备份。
是的，我也不喜欢那个论点。我有99％的时间都有良好的互联网连接，而且不足以成为一个问题： - ）
- 离线或在飞机上工作。 [...]
然而，真正的论点并不是你离线，而是你可以假装离线。更准确地说，您可以独立工作，而无需立即将更改发送到中央存储库。
DVCS工具是围绕人们可能脱机工作的想法而设计的。这有许多重要的后果：
合并分支变得很自然。当人们可以并行工作时，叉子自然会出现在提交图中。因此，这些工具在合并分支时必须非常好。一个工具SVN is not very good at merging！
Git，Mercurial和其他DVCS工具合并得更好，因为他们在这方面有更多的测试，而不是直接因为它们是分布式的。
更灵活。使用DVCS，您可以自由地在任意存储库之间进行推/拉变换。我经常在我的家和计算机之间推/拉，而不使用任何真正的中央服务器。当事情准备好发布时，我会把它们推到像Bitbucket这样的地方。
多站点同步不再是＆＃34;企业功能＆＃34;，它是内置功能。因此，如果您有离岸位置，他们可以设置本地集线器存储库并在它们之间使用它。然后，您可以每天，每天或何时适合您同步本地集线器。这只需要定期运行hg pull或git fetch的cronjob。
更好的可扩展性，因为客户端有更多逻辑。这意味着对中央服务器和更强大的客户端工具的维护更少。
使用DVCS，我希望能够通过修改代码（而不仅仅是提交消息）进行关键字搜索。使用集中式工具，您通常需要设置一个额外的索引工具。
答案 3 :(得分：6)
DVCS对我来说非常有趣：
为source control流程添加了全新维度：发布。
您不仅拥有merge workflow，还拥有一个发布工作流程（您将向哪个存储库推送/推送），这可能会产生许多含义：
带来了 producing/consuming revisions 的新方式：
这意味着你不依赖于其他人将他们的工作交给中央回购，但你可以与不同的演员和他们的回购有更直接的关系。
答案 4 :(得分：2)
关于IDE为您进行跟踪的中心论点是错误的。除了无限制的撤销级别之外，大多数IDE实际上没有任何此类功能。想想分支，合并，恢复，提交消息（日志）等等，我敢打赌，即使你所提到的IDE也不尽如人意。特别是我怀疑它跟踪你的提交 - 很可能在你工作的几个不同的分支上 - 并且一旦你上线就正确地将它们推送到存储库。
如果您的IDE实际上完成了所有这些，我实际上将其称为分布式版本控制系统。
最后，如果中央存储库由于某种原因而死亡（您的服务提供商破产，发生了火灾，黑客破坏了它，......），您最近在每台机器上都有一个完整备份
编辑：您可以像使用集中式存储库一样使用DVCS，我甚至建议至少为中小型项目使用DVCS。拥有一个始终在线的中央“权威”存储库简化了很多事情。当该计算机崩溃时，您可以暂时切换到其他计算机之一，直到服务器得到修复。答案 5 :(得分：1)
如果你没有看到本地历史或本地版本的价值，那么我不确定任何数量的问答都会改变你的想法。
IDE的历史特征是有限且笨拙的。它们与完整的功能完全不同。
如何使用这些东西的一个很好的例子是各种Apache项目。我可以将git repo同步到Apache svn repo。然后，我可以在一个私人分支中工作一个星期。我可以从回购中删除更改。我可以报告我的变化，零售或批发。当我完成后，我可以将它们打包为一次提交。
答案 6 :(得分：1)
有趣的问题。
我不是一个经验丰富的DVCS用户，但我的有限曝光感觉非常积极。
我喜欢能够两步提交。这适合我。
我想到的一些优点：
更好的合并支持。 Branch-Merge感觉更像是DVCS的一等公民，而在我的集中式解决方案的经验中，我发现它是痛苦和棘手的。现在可以在svn中使用合并跟踪，但它仍然很慢且很麻烦。
大型团队。 DVCS不仅适用于单用户提交。你可以推动＆amp;在返回主存储库之前拉取团队之间的提交（或不）。这对某些合作风格非常宝贵。
在处理实验性功能时，经常提交是有意义的，但仅限于短期。我不想总是分支主代码库，所以能够播放＆amp;重新录制。同样，我可以看到它在使用持续集成时很有用。如果我在重构工作上工作了好几天，我可能会在不可接受的时间范围内打破构建，但我仍然想跟踪我的更改。
请注意，我对使用Mercurial的DVCS体验比使用Git更多。来自CVS / SVN背景，我发现使用Mercurial（Hg）可以更轻松地学习曲线。最近添加的对Mercurial的Google Code支持也是一个福音。 ......我甚至可以说，我对Git的初步反应是消极的，但更多的是从可用性的角度来看，而不是与DVCS有关的任何事情
答案 7 :(得分：1)
可能有趣的是，Subversion将来可能会得到类似offline commits的内容。当然，我们无法将这些功能与当前可用的功能进行比较，但这可能是“以集中方式使用DVCS”的一种非常好的方式，如此处其他答案中所述。
另一个recent post声明Subversion并未尝试成为DVCS
这些事情可能意味着存储库仍然是集中的，这意味着你不能进行断开连接的分支，旧版本的差异，但你可以排队提交。
答案 8 :(得分：1)
我不打算在这里卖东西。
•在本地提交的优势或价值是什么？什么？真？ 所有现代IDE都可以让您跟踪您的更改？而如果 要求您可以恢复特定的更改。而且，他们有一个 功能，以在IDE级别标记您的更改/版本！？
唯一真正的优势是您不需要连接到主中央存储库。有人可以说，Git的好处是开发人员可以在本地提交，准备一个很好的补丁组合，然后将它们拉到有福的中央回购，但IMO这是非常无趣的。开发人员可以使用Subversion存储库中的私有托架或分支来处理他的任务，然后将其与主线（例如/ trunk）或其他分支合并。
对我来说，这里的主要缺点是我必须在我的机器上下载并存储整个Git存储库。随着一个历史悠久的大项目，它变得痛苦并占用太多空间。
集中的另一个缺点是Git technically can't track renames or copy operations。它只是tries to guess whether a file was renamed or copied based on the file's content。这导致了这样一些有趣的案例：svn to git migration keeping history of copied file（盖伊问为什么SVN＆gt; Git迁移后文件的历史记录丢失了。）。
•如果我的硬盘坏了怎么办？我的本地存储库在哪里？ （所以 与登记中央仓库相比，它有何凉爽？）
使用Git，如果您崩溃了本地存储设备（硬盘驱动器，固态硬盘，无论如何），并且它没有被拉动或推送到受祝福的Git的回购中，那么您就不走运了。你刚刚浪费了时间和代码。除此之外，硬盘驱动器与本地Git仓库的崩溃可能会暂停开发过程一段时间：Linus Torvald's SSD breaks, halts Linux kernel development。
使用SVN等集中式源代码控制，您只能丢失上一次提交，因为您的所有工作已经提交到中央存储库，分支，私有货架甚至是主干。显然，您应该确保为您的中央存储库实施灾难恢复和备份。
•Ok Linus Torvalds将自己的生命献给了Git并且讨厌其他一切。 这是否足以盲目地赞美赞美？莱纳斯生活在一个不同的地方 世界与我的中型项目的离岸开发商相比？
对于像以前使用BitKeeper的Linux Kernel这样的项目，Git是最好的源代码控制系统！但我说Git并不适合所有人。
明智地选择！
答案 9 :(得分：-1)
最有可能的是，没有人会在这里卖给你任何东西。如果您需要git的功能，只需git init。如果它不适合你，那就不要。
如果您还不知道git功能，请在Google搜索中输入git vs（注意结束空间），然后查看自动填充功能的结果。
在我需要Netbeans功能之前，我首选IDE键盘。似乎这是同样的情况。
如您所知，有许多没有VCS的成功项目。
PS。卖git违反了它的许可证！ ;）