我已经使用Subversion很多年了,在使用SourceSafe之后,我爱上了Subversion。结合TortoiseSVN,我真的无法想象它还能有什么更好的。

然而,越来越多的开发人员声称Subversion存在问题,我们应该转向新的分布式版本控制系统,比如Git。

Git如何改进Subversion?


当前回答

使用Git,您几乎可以脱机做任何事情,因为每个人都有自己的存储库。

创建分支和合并分支非常简单。

即使你没有项目的提交权限,你仍然可以拥有自己的在线存储库,并发布补丁的“推送请求”。每个喜欢你的补丁的人都可以把它们拉到他们的项目中,包括官方的维护者。

分叉一个项目,修改它,并仍然从HEAD分支中合并错误修复是很简单的。

Git适用于Linux内核开发人员。这意味着它非常快(必须如此),并且可以扩展到数千个贡献者。Git使用的空间也更少(Mozilla存储库的空间最多减少30倍)。

Git非常灵活,非常TIMTOWTDI(有不止一种方法可以做到)。你可以使用任何你想要的工作流,Git会支持它。

最后,还有GitHub,一个托管Git存储库的好网站。

Git的缺点:

它更难学,因为Git有更多的概念和命令。 修订版不像subversion那样有版本号 许多Git命令是神秘的,错误消息对用户非常不友好 它缺少一个好的GUI(比如伟大的TortoiseSVN)

其他回答

SubVersion最让我恼火的一点是它把自己的文件夹放在项目的每个目录中,而git只把一个文件夹放在根目录中。这不是什么大事,但这样的小事积少成多。

当然,SubVersion有Tortoise,它(通常)非常好。

这一切都是关于做某事所需的易用性/步骤。

如果我在我的PC/笔记本电脑上开发一个项目,git会更好,因为它的设置和使用要容易得多。 合并时不需要服务器,也不需要一直输入存储库URL's in。

如果只有两个人,我会说git也更简单,因为你可以互相推拉。

一旦你超越了这一点,我就会选择颠覆,因为在这一点上你需要设置一个“专用”服务器或位置。

使用git可以像使用SVN一样做到这一点,但是git的好处被需要执行额外步骤来与中央服务器同步所抵消。在SVN中,你只需要提交。在git中,你必须先执行git commit,然后再执行git push。额外的步骤很烦人,因为你最后做了太多。

SVN也有更好的GUI工具的好处,但是git生态系统似乎正在迅速追赶,所以从长远来看我并不担心这一点。

David Richards关于Subversion / GIT的WANdisco博客

The emergence of GIT has brought with it a breed of DVCS fundamentalists – the ‘Gitterons’ – that think anything other than GIT is crap. The Gitterons seem to think software engineering happens on their own island and often forget that most organizations don’t employ senior software engineers exclusively. That’s ok but it’s not how the rest of the market thinks, and I am happy to prove it: GIT, at the last look had less than three per cent of the market while Subversion has in the region of five million users and about half of the overall market. The problem we saw was that the Gitterons were firing (cheap) shots at Subversion. Tweets like “Subversion is so [slow/crappy/restrictive/doesn't smell good/looks at me in a funny way] and now I have GIT and [everything works in my life/my wife got pregnant/I got a girlfriend after 30 years of trying/I won six times running on the blackjack table]. You get the picture.

Git和DVCS通常都非常适合于独立编写大量代码的开发人员,因为每个人都有自己的分支。但是,如果您需要从其他人那里进行更改,她必须提交给她的本地回购,然后她必须将该更改集推给您,或者您必须从她那里获取更改集。

我自己的推理也让我认为,如果你做集中发布之类的事情,DVCS会让QA和发布管理变得更加困难。必须有人负责从其他人的存储库中进行推送/拉取,解决任何在最初提交时就可以解决的冲突,然后进行构建,然后让所有其他开发人员重新同步他们的回购。

当然,所有这些都可以通过人工流程来解决;DVCS只是破坏了一些由集中式版本控制修复的东西,以便提供一些新的便利。

一些回答已经提到了这些问题,但我想明确说明两点:

1)有选择性提交的能力(例如,git add——patch)。如果您的工作目录包含多个不属于同一逻辑更改的更改,Git可以很容易地提交只包含部分更改的提交。对于Subversion,这是很困难的。

2)在不公开更改的情况下提交的能力。在Subversion中,任何提交都是立即公开的,因此是不可撤销的。这极大地限制了开发人员“尽早提交,经常提交”的能力。

Git不仅仅是一个VCS;它也是一个开发补丁的工具。Subversion只是一个VCS。