可靠性

如果你的硬盘开始悄无声息地破坏数据,你很想知道它。Git对你所做的每件事都进行了一次哈希运算。你有一个SVN的中央回购协议,如果它的位被一个有故障的硬盘控制器悄悄地修改,你不会知道,直到它太晚了。

既然你有一个中央回购, 你把你唯一的生命线给炸了 .

用Git, 每个人 有一个相同的回购协议,完整的变更历史,其内容可以完全信任,因为sha1的完整形象。因此,如果你备份你的头的20字节sha1,你可以肯定,当你从某个不受信任的镜像克隆,你有完全一样的回购你失去了!

分支(和命名空间污染)

当你使用集中回购时,所有的分行都在那里供全世界看到。你不能开私人分行。你必须建立一个分支,而不是与其他全局名称冲突。

“ test123 --该死,已经有一个 测试123 . 让我们试试 test124 “

每个人都必须看到这些有愚蠢名字的分支。你必须服从公司的政策,这可能会遵循“除非你 真正地 “需要”,这阻止了git带来的许多自由。

和承诺一样。当你承诺的时候,你最好是 真正地 当然你的代码是有效的。否则你会破坏建筑。没有中间承诺。”因为他们都去中央回购。

跟吉特在一起你一点也不胡说。分支并在本地提交所有您想要的内容。当你准备向世界其他地方公开你的更改时,你会要求他们从你身上撤走,或者把它推到某个“主要”的git回购协议上。

性能

因为你的回购协议是本地的,所有的风险投资操作 快速的 而且不需要往返和从中央服务器转移! git log 不必通过网络查找更改历史。Svn确实如此。与所有其他命令相同,因为所有重要的内容都存储在 一个位置 !

手表 Linus' talk 与SVN相比,这些和其他好处。

我一直在你现在的位置,对分布式版本控制的使用持怀疑态度。我读过所有的文章,知道理论上的论点,但我不相信。

直到有一天,我打字 git init 突然发现自己在一个git仓库里。

我建议你也这么做——试试看。从一个小的爱好项目开始,只是为了掌握它的窍门。然后决定它是否值得用于更大的东西。

我是 Mercurial 开发人员,曾担任过多变的顾问。所以我觉得你的问题很有趣,希望我能回答:

• 在本地提交有什么好处或价值?[…]

现在IDE可以跟踪本地更改,而不仅仅是简单的撤消/重做,这是正确的。但是,这些文件快照与完整版本控制系统之间的功能仍有差距。

本地提交使您可以选择在提交供审阅之前在本地准备“故事”。我经常做一些涉及2-5次提交的更改。在我执行commit 4之后,我可能会返回并稍微修改commit 2(也许在我执行commit4之后,我在commit2中看到了一个错误)。这样,我不仅要处理最新的代码,还要处理最后两个提交。当所有内容都是本地的时,这是很可能的,但是如果需要与中心服务器同步,则会变得更加棘手。

• 如果我的硬盘坏了怎么办?[…]那么,与签入中央回购协议相比,有什么酷的呢?

一点也不酷!-)

然而,即使是中央回购,你仍然需要担心 未提交的数据 在工作副本中。因此,我认为你无论如何都应该有一个备份解决方案。

根据我的经验,人们通常在工作副本中有更大的未精简数据块,这些数据块是由一个集中的系统提供的。客户告诉我他们是如何说服开发人员至少承诺 一周一次 .

由于以下原因,这些更改通常不进行斜接:

1. 他们还没有真正完成。代码中可能有调试打印语句,可能有不完整的函数等。

2. 承诺将进入 trunk 那就是 危险的 因为它会影响到其他人。

3. 承诺需要你先 合并 与中央存储库。如果您知道对代码进行了其他冲突更改,则合并可能会很吓人。合并可能很烦人,因为您可能没有完成所有的更改,您更喜欢在已知的良好状态下工作。

4. 当您必须与超载的中心服务器通信时,提交可能会很慢。如果你在一个离岸的地方,提交会更慢。

你是 绝对正确 如果您认为以上并不是集中版本控制和分布式版本控制的问题。使用cvcs,人们可以在不同的分支中工作,因此可以轻松地避免上面的2和3。有了一个单独的丢弃分支,我也可以提交任意数量的内容,因为我可以创建另一个分支,在其中提交更完善的更改(解决方案1)。但是提交仍然很慢,所以4仍然可以应用。

使用dvcs的人通常会将他们的“本地”承诺作为穷人的备份解决方案推送到远程服务器上。他们不会推到团队其他成员工作的主服务器,而是推到另一个(可能是私有)服务器。这样,他们就可以独立工作,并且仍然保留非现场备份。

• 脱机工作或在飞机上工作。[…]

是啊,我也不喜欢这种说法。我99%的时间都有很好的互联网连接,但飞得不够快,这就成了一个问题:-)

然而,真正的论点不是你离线了,而是你可以 假装 离线。更准确地说,您可以独立工作,而不必立即将更改发送到中央存储库。

dvcs工具的设计理念是人们可以离线工作。这有许多重要的后果:

• 合并分支成为一件自然的事情。当人们可以并行工作时,fork自然会出现在commit图中。因此,这些工具必须 真的很好 在合并分支时。这样的工具 SVN is not very good at merging !

  git、mercurial和其他dvcs工具 合并更好 因为他们在这个领域有更多的测试,而不是直接因为他们是分布式的。

• 更灵活。使用dvcs,您可以自由地在任意存储库之间推/拉更改。我经常在家用电脑和工作电脑之间推拉,而不使用任何真正的中央服务器。当事情准备好发表时,我会把它们推到一个像Bitbucket这样的地方。

  多站点同步不再是“企业功能”,而是一个内置功能。因此,如果您有一个离岸位置,他们可以建立一个本地中心存储库,并在他们之间使用。然后,您可以每天或在适合您的时间同步本地集线器。这只需要运行一个cronjob hg pull 或 git fetch 每隔一段时间。

• 更好的可伸缩性,因为客户端有更多的逻辑。这意味着中央服务器的维护更少,客户端工具更强大。

  使用DVCS,我希望能够通过 代码 (不仅仅是提交消息)。对于集中式工具,通常需要设置额外的索引工具。

DVCS对我来说非常有趣,因为它:

• 将全新维度添加到 source control 过程: 出版 .
  你不只是 merge workflow ,您还有一个发布工作流(您将从哪个存储库推送到/拉到哪个存储库),它可以有许多含义:

  • 开发生命周期(只有为特定类型的提交而创建的存储库,比如为了部署而创建的发布到productions中的存储库)
  • 单独任务(您可以推送和更新备份回购,即使在 form of just one file )
  • 相互依赖项目(当项目A的一个团队等待项目B最终提交到中央回购协议时,它可能会要求B将中间开发作为邮件中的附加ZIP文件“传递”。现在,A所要做的就是添加B回购作为一个潜在的远程,获取它并查看一下)

• 带来一种新的方式 producing/consuming revisions 用:

  • 一 被动生产方式 新的修订版(只有积极从回购中撤出的修订版才会在其分支机构中看到)
  • 安 积极的消费方式 来自其他人的修订(通过将他们的回购协议添加为远程并从中获取/合并所需内容)。

这意味着您不依赖于其他人将其工作交付给中央回购,而是可以与不同的参与者及其回购建立更直接的关系。

你关于ide为你跟踪的中心论点是错误的。事实上,除了无限的撤销级别之外,大多数ide都没有这样的功能。想想分支、合并、还原、提交消息(日志)等等,我敢打赌,就连你提到的ide也不够。尤其是我怀疑它是否跟踪了您的提交(很可能是在您工作的几个不同分支上),并在您联机后将它们正确地推送到存储库中。

如果你的ide真的这么做了,我实际上会称它为一个分布式版本控制系统。

最后,如果中央存储库由于任何原因而死亡(您的服务提供商破产、发生火灾、黑客破坏了它,…),那么您在最近取出存储库的每台计算机上都有一个完整的备份。

编辑:您可以像使用集中存储库一样使用dvcs,我甚至建议至少在中小型项目中这样做。拥有一个始终在线的中央“权威”存储库可以简化很多事情。当那台机器崩溃时,你可以暂时切换到另一台机器,直到服务器得到修复。

如果你看不到本地历史或本地构建的价值,那么我不确定回答任何问题都会改变你的想法。

ide的历史特性是有限的和笨拙的。它们完全不同于功能。

一个很好的例子说明了这些东西是如何在各种apache项目中使用的。我可以将git repo同步到apache svn repo。那我就可以自己在一家私人分行工作一周了。我可以从回购协议中删除更改。我可以报告我的变化,零售或批发。完成后,我可以将它们打包为一个提交。

有趣的问题。

我不是一个经验丰富的dvcs用户,但我有限的接触已感到非常积极。

我喜欢两步到位。这对我很合适。

想到了一些好处:

1. 更好的合并支持。分支合并感觉更像是DVCS的一等公民,而在我集中解决方案的经验中,我发现这是痛苦和诡计。合并跟踪现在在svn中是可用的,但是它仍然是缓慢和繁琐的。

2. 大型团队。dvcs不仅适用于单用户提交。您可以在团队之间推送和拉取提交,然后再向主存储库投稿(或不投稿)。这对于某些合作的味道来说是无价的。

3. 在进行实验性功能时,经常提交是有意义的,但仅限于短期。我不想总是分支主代码库,所以能够播放和重新录制很好。类似地,我可以看到它在处理连续集成时非常有用。如果我在重构工作上花了几天的时间,我可能会在一个不可接受的时间段内中断构建,但我仍然想跟踪我的更改。

请注意,我的dvcs体验更多的是mercurial而不是git。来自cvs/svn的背景,我发现mercurial(hg)的学习曲线要容易得多。最近增加的google代码对mercurial的支持也是一个福音。 …我甚至会说,我对git的最初反应是否定的,但更多的是从可用性的角度考虑,而不是从dvcs的角度考虑。

注意到subversion可能会得到 offline commits 未来。当然,我们无法将这些功能与目前可用的功能进行真正的比较,但这可能是“以集中方式使用dvcs”的一个非常好的方法,如这里的其他答案所述。

另一 recent post 声明Subversion不想成为DVCS

这些事情可能意味着存储库仍然是集中的,这意味着您不能执行断开连接的分支,旧版本的扩散,但是您可以将提交排队。

我不会在这里卖东西的。

在本地提交有什么好处或价值?什么?真的? 所有的现代ide都允许您跟踪自己的变化?如果 必需您可以还原特定更改。而且,他们有一个 在IDE级别标记更改/版本的功能!?

唯一真正的优势是不需要连接到主中央存储库。有人可以说,git的好处在于,开发人员可以在本地提交补丁,准备一个很好的补丁组合,然后将它们拉到受祝福的中央回购协议中,但在我看来,这是相当无趣的。开发人员可以使用subversion存储库中的一个私有shelve或一个分支来完成他的任务,然后将其与一条主线(例如/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>git迁移之后文件的历史记录丢失了,)。

如果我的硬盘坏了怎么办?我的本地存储库去了哪里?(所以) 与签入中央回购协议相比,这有多酷?

有了git,如果您崩溃了本地存储设备(hdd、ssd等等),并且它的更改没有被拉入或推送到受祝福的git的repo中,那么您就失去了运气。你刚刚失去了你的时间和代码。除此之外,本地Git回购的硬盘驱动器崩溃可能会在一段时间内停止开发过程: Linus Torvald's SSD breaks, halts Linux kernel development .

使用集中的源代码管理(如svn),您只能丢失最后一次提交,因为您的所有工作都已提交到中央存储库的分支、专用搁置区甚至主干。显然,您应该确保为中心repo实施了灾难恢复和备份。

好吧,莱纳斯·托瓦尔兹把他的生命交给了吉特,他讨厌其他一切。 这足以盲目地赞美吗?莱纳斯住在一个不同的地方 与我的中型项目中的海外开发商相比?

对于过去使用bitkeeper的linux内核这样的项目,git是最好的源代码管理系统!但我认为git并不适合所有人。

明智地选择!

很可能,这里没人会卖给你任何东西。如果你需要git的特性,只要 git init . 如果不适合你,就不要。

如果您还不知道git的特性,请键入 git vs (注意结尾的空格)在google搜索中,并查看自动完成的结果。

在需要netbeans特性之前,我更喜欢记事本而不是ide。看来这里也是这样。

你知道,很多成功的项目根本没有风投。

销售git违反了它的许可证!;)