出售我的分布式版本控制
我知道1000多个类似的话题。 我在这里读了5条线，但为什么我还不确信DVCS呢？
我只有以下几个问题（注意我只是自私地担心Java项目）
- 什么是本地提交的优点或价值？ 什么？ 真？ 所有现代IDE允许你跟踪你的变化？ 如果需要，你可以恢复一个特定的变化。 此外，他们有一个function来标记您的更改/版本在IDE级别！？
- 如果我的硬盘崩溃怎么办？ 我的本地存储库在哪里？ （那么和login中央仓库相比，它有多酷？）
- 离线或在飞机上工作。 有什么大不了的？为了让我用我的修改来构build发行版，我最终必须连接到中央存储库。 直到那时，我怎么跟踪我的变化在本地并不重要。
- 好的Linus Torvalds把自己的生命献给了Git，并讨厌其他一切。 这是否足以盲目地赞美？ 与我的中型项目中的海外开发人员相比，Linus与世界不同？
打我！
可靠性
如果你的硬盘默默地开始破坏数据，你该死的想知道它。 Git把所有你提交的东西都做成SHA1哈希值。 你有一个SVN的中央回购，如果它的位得到一个错误的HDD控制器默默修改，你不会知道它，直到为时已晚。
而且由于你有一个中央回购， 你只是吹了你唯一的生命线 。
使用git， 每个人都有一个完全相同的repo，包含更改历史logging，由于其完整映像的SHA1，其内容可以完全信任。 所以如果你备份你的HEAD的20字节的SHA1，你可以肯定的是，当你从一个不可信的镜像克隆，你有完全相同的回购你失去了！
分支（和命名空间污染）
当你使用一个集中的回购，所有的分支在那里为世界看到。 你不能build立私人分支。 您必须创build一些尚未与其他全局名称相冲突的分支。
“
test123– 该死的，已经有test123试试看test124。
而且每个人都必须以愚蠢的名字看到所有这些分支。 你必须屈服于公司的政策，可能会沿着“除非你真的需要build立分支机构”的路线，这阻止了你用git获得的很多自由。
与提交相同。 当你提交时，你最好确定你的代码工作。 否则，你打破构build。 没有中间提交。 因为他们都去中央回购。
用git你没有这个废话。 分支并提交本地所有你想要的。 当你准备好将你的改变暴露给世界其他地方时，你可以让他们从你那里拉，或者把它推到一些“主”的git回购。
性能
由于您的回购是本地的，所有的VCS操作都很快 ，不需要往返中转服务器！ git log不必通过networking查找更改历史logging。 SVN呢。 与所有其他命令一样，因为所有重要的东西都存储在一个位置 ！
观看Linus谈论 SVN的这些和其他好处。
我一直在这里，怀疑分布式版本控制的使用。 我已经阅读了所有的文章，并且知道理论上的论点，但我并不确信。
直到有一天，我input了git init并突然发现自己在一个git仓库中。
我build议你也这样做 – 只需要尝试一下。 从一个小的爱好项目开始，只是为了得到它的挂钩。 然后决定是否值得使用更大的东西。
我是Mercurial开发人员，曾担任Mercurial顾问。 所以我觉得你的问题非常有趣，希望我能回答他们：
- 什么是本地提交的优点或价值？ […]
IDE是正确的，除了简单的撤销/重做这些日子之外，它们可以跟踪本地的变化。 但是，这些文件快照和完整版本控制系统之间的function仍然存在差距。
当地提交给你在提交审查之前在本地准备你的“故事”的选项。 我经常做一些涉及2-5次提交的更改。 在我做了提交4之后，我可能会稍微回头修改提交2（也许我在提交4后看到了提交2中的错误）。 这样，我将不仅在最新的代码，而且在最后几个提交。 当一切都是本地的时候，这可能是微不足道的，但是如果你需要与中央服务器同步的话，这变得更加棘手。
- 如果我的硬盘崩溃怎么办？ 与签入中央仓库相比，它有多酷？
一点都不酷！ 🙂
但是，即使有一个中央仓库，你仍然不得不担心工作副本中的数据不完整 。 因此，我认为你应该有一个备用的解决scheme。
根据我的经验，人们通常会在工作副本中使用集中式系统来存储大量的无限数据。 客户告诉我他们是如何试图说服开发者每周至less承诺一次 。
这些变化通常是不受欢迎的，因为：
-
他们没有真正完成。 代码中可能有debugging打印语句，可能会有不完整的函数等。
-
承诺会进入
trunk，这对中央系统是危险的 ，因为它影响到其他人。 -
提交将需要您先与中央存储库合并 。 如果您知道代码中还有其他冲突的变化，那么这种合并可能会让人感到恐惧。 合并可能只是令人讨厌，因为你可能没有完成所有的变化，你更喜欢从一个已知的状态工作。
-
当您必须与超负荷的中央服务器通话时，提交速度会变慢。 如果你在离岸位置，提交更慢。
如果您认为上述内容不是集中式与分布式版本控制的问题，那么您绝对正确 。 通过CVCS，人们可以在不同的分支上工作，从而避免了上面的2和3。 用一个单独的丢弃分支，我也可以提交尽可能多的，因为我可以创build另一个分支，我承诺更多的抛光改变（解决1）。 虽然提交仍然很慢，所以仍然可以应用4。
使用DVCS的人通常会将其“本地”提交作为穷人的备份解决scheme推送到远程服务器。 他们不会推送到其他团队正在工作的主服务器，而是推送到另一个（可能是私人的）服务器。 这样他们可以孤立地工作，仍然保持异地备份。
- 离线或在飞机上工作。 […]
是的，我也从来不喜欢这个论点。 我有99％的时间有良好的互联网连接，并没有足够的飞行这是一个问题:-)
但是，真实的说法并不是你不在线，而是你可以假装离线。 更准确地说，您可以单独工作，而无需立即将更改发送到中央存储库。
DVCS工具是围绕着人们可能离线工作的想法而devise的。 这有一些重要的后果：
-
合并分支成为一件自然的事情。 当人们可以并行工作时，叉会自然出现在提交图中。 因此，这些工具必须非常擅长合并分支机构。 像SVN这样的工具并不是很好的合并 ！
Git，Mercurial和其他DVCS工具合并得更好，因为它们在这方面有更多的testing，而不是直接分发。
-
更灵活。 使用DVCS，您可以自由地在任意存储库之间推/拉变更。 我经常会在家用电脑和工作电脑之间推/拉，而不使用任何真正的中央服务器。 当准备发布的时候，我把它们推到一个像Bitbucket的地方。
多站点同步不再是“企业function”，而是一种内置function。 所以，如果你有一个离岸位置，他们可以设置一个本地中心库，并在他们自己之间使用。 然后，您可以每天同步本地中心，也可以在适合您时进行同步。 这只需要一个定期运行
hg pull或git fetch的cronjob。 -
更好的可扩展性，因为更多的逻辑在客户端。 这意味着在中央服务器上维护更less，function更强大的客户端工具。
使用DVCS，我希望能够通过修改代码 （而不仅仅是提交消息）来进行关键字search。 使用集中式工具时，通常需要设置额外的索引工具。
DVCS对我来说非常有趣，因为它：
-
将全新的维度添加到源代码pipe理进程： 发布 。
你不只是有一个合并工作stream程 ，你也有一个发布工作stream程（你将推送到哪个存储库），这可以有很多的含义：- 开发生命周期（只为特定types的提交创build存储库，例如为了部署目的而发布到分支）
- 独奏任务（您可以推送和更新备份回购，即使只是一个文件的forms ）
- 相互依赖项目（当一个项目组A正在等待团队项目B最终落实到中央仓库时，可能会要求B将一个中间开发项目作为一个附加的zip文件“传递”到邮件中。 A必须做的是添加B回购作为一个潜在的远程，获取它并偷看）
-
带来了一个新的生产/消费修订方式：
- 一个被动的方式来产生新的修订（只有从你的回购积极拉动的那一个将在他们的分支中看到他们）
- 一种积极的方式来消费其他人的修改（通过添加他们的回购作为远程和获取/合并你所需要的）。
这意味着你不需要依靠其他人将他们的工作交给中央回购，而是可以与不同的angular色和回购者有更直接的关系。
你关于IDE跟踪你的主要观点是错误的。 除了无限的撤销级别之外，大多数IDE实际上并没有任何这样的function。 想想分支，合并，还原，提交消息（日志）等，我敢打赌，即使是你所指的IDE也不足。 特别是我怀疑它跟踪你的提交 – 很可能在你工作的几个不同的分支 – 一旦你上网，正确推送他们到存储库。
如果你的IDE实际上做了这些，我实际上将其称为分布式版本控制系统。
最后，如果中央资料库因为什么原因（您的服务提供商破产，出现了火灾，黑客破坏了它）而死亡，那么您最近在每台机器上都有完整的备份。
编辑：你可以使用一个DVCS就像一个集中的存储库，我甚至会build议这样做，至less对于中小型项目。 拥有一个始终在线的中央“权威”存储库简化了许多事情。 当机器崩溃时，您可以暂时切换到其他机器之一，直到服务器得到修复。
如果你没有看到当地历史或当地build筑的价值，那么我不确定任何数量的问题回答都会改变你的想法。
IDE的历史function是有限和笨拙的。 他们不像完整的function。
一个很好的例子是如何使用这个东西在各种Apache项目上。 我可以同步一个git仓库到Apache svn仓库。 然后，我可以在私人部门工作一个星期。 我可以从回购股份下跌。 我可以报告我的变化，零售或批发。 当我完成后，我可以将它们打包成一个提交。
有趣的问题。
我不是一个经验丰富的DVCS用户，但我有限的曝光感觉非常积极。
我喜欢能够两步承诺。 这适合我。
想到的一些优点：
-
更好地合并支持。 Branch-Merge感觉更像DVCS中的一等公民，而在我的集中解决scheme经验中，我发现这是一个痛苦和棘手的问题。 合并跟踪现在在svn可用，但它仍然是缓慢和麻烦。
-
大型团队。 DVCS不仅适用于单用户提交。 您可以在推送回主存储库之前推送和拉队之间的提交（或不提供）。 这对于某些合作风格是非常有价值的。
-
在研究实验function时，经常提交是有意义的，但仅限于短期。 我不想总是分支主要的代码库，所以很高兴能够播放和重新录制。 同样，我可以看到它在使用持续集成时很有用。 如果我在重构工作上工作了几天，我可能会破坏构build一个不可接受的时间框架，但我仍然想跟踪我的变化。
请注意，我的DVCS体验比使用Git更多。 来自CVS / SVN的背景，我发现Mercurial（Hg）的学习曲线更容易。 最近添加的对Mercurial的Google Code支持也是一个福音。 …我甚至会说，我对Git的初步反应是负面的，但更多的是从可用性的angular度来看，比任何与DVCS
可能有趣的是，Subversion将来可能会获得离线提交的function。 当然，我们不能真正比较这些function与当前可用的function，但这可能是一个非常好的方式来“集中使用DVCS”，如其他答案中所述。
另一个最近的post指出Subversion并不想成为DVCS
这些东西可能意味着版本库仍然是集中的，这意味着你不能做不连接的分支，旧版本的差异，但你可以排队提交。
我不打算在这里卖东西。
•本地提交的优点或价值是什么？ 什么？ 真？ 所有现代IDE允许你跟踪你的变化？ 如果需要，你可以恢复一个特定的变化。 此外，他们有一个function来标记您的更改/版本在IDE级别！？
唯一的好处是你不需要连接到主中央仓库。 有人可以说，Git的好处在于开发人员可以在本地犯下错误，准备好补丁组合，然后将它们拖到受保护的中央回购站，但是IMO对此并不感兴趣。 开发人员可以使用私有架构或Subversion版本库中的分支来处理他的任务，然后将其与主线（例如/ trunk）或其他分支合并。
对我来说，这里的主要缺点是我必须下载和存储整个Git仓库在我的机器上。 一个有looong历史的大型项目会变成一个痛苦，需要太多的空间。
集中化的另一个缺点是Git在技术上不能跟踪重命名或复制操作 。 它只是试图猜测文件是根据文件的内容重命名还是复制的 。 这导致了这样一些有趣的情况： svn to git migration保留了复制文件的历史logging （Guy在问SVN> Git迁移之后为什么文件的历史已经丢失）。
•如果我的硬盘崩溃怎么办？ 我的本地存储库在哪里？ （那么和login中央仓库相比，它有多酷？）
有了Git，如果你崩溃了你的本地存储设备（硬盘，固态硬盘，无论什么），它的变化没有被拉到或推到一个幸运的Git的回购，那么你是运气不好。 你刚刚失去了你的时间和你的代码。 除此之外，使用本地Git回购的硬盘崩溃可能会暂停开发过程一段时间： Linus Torvald的SSD中断了，停止了Linux内核的开发 。
通过像SVN这样的集中式源代码控制，你只能失去最后一次提交，因为你所有的工作已经被提交到分支机构，私有架构甚至中继的中央存储库。 显然，您应该确保为您的中央仓库实施灾难恢复和备份。
好的，Linus Torvalds把自己的生命献给了Git，并且憎恨其他一切。 这是否足以盲目地赞美？ 与我的中型项目中的海外开发人员相比，Linus与世界不同？
对于过去使用过BitKeeper的Linux Kernel这样的项目，Git是最好的源代码控制系统！ 但是我会说Git不适合每个人。
做出明智的select！
最有可能的是，没有人会在这里推销任何东西。 如果你需要git的function，只需要git init 。 如果它不适合你，就不要。
如果您还不知道gitfunction，请在Googlesearch中inputgit vs （注意结尾空格），然后查看自动完成的结果。
直到我需要Netbeansfunction，我更喜欢记事本。 似乎这里也是这样。
如你所知，有许多没有VCS的成功项目。
PS。 卖git违反了它的许可证！ ;）
