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

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

Git如何改进Subversion?


当前回答

Subversion非常容易使用。在过去的几年里,我从来没有发现任何问题或事情没有像预期的那样工作。此外,还有许多优秀的GUI工具,对SVN集成的支持也很大。

With Git you get a more flexible VCS. You can use it the same way like SVN with a remote repository where you commit all changes. But you can also use it mostly offline and only push the changes from time to time to the remote repository. But Git is more complex and has a steeper learning curve. I found myself in the first time committing to wrong branches, creating branches indirectly or get error messages with not much informations about the mistake and where I must search with Google to get better informations. Some easy things like substitution of markers ($Id$) doesn't work but GIT has a very flexible filtering and hook mechanism to merge own scripts and so you get all things you need and more but it needs more time and reading of the documentation ;)

如果您主要脱机使用本地存储库,那么如果本地机器上丢失了某些东西,则没有备份。使用SVN,您主要使用远程存储库,同时您的备份也在另一个服务器上… Git也可以以同样的方式工作,但这并不是Linus的主要目标,要有类似SVN2的东西。它是为Linux内核开发人员和分布式版本控制系统的需要而设计的。

Git比SVN好吗?只需要一些版本历史记录和备份机制的开发人员可以轻松地使用SVN。经常使用分支、同时测试更多版本或主要离线工作的开发人员可以从Git的特性中受益。有一些非常有用的特性,比如SVN中没有的存储特性,可以使工作更轻松。但另一方面,并非所有人都需要所有功能。所以我看不到SVN的死角。

Git需要一些更好的文档,错误报告必须更有帮助。而且现有的有用的gui也很少。这次我只找到了一个支持大多数Git特性的Linux GUI (Git -cola)。Eclipse集成正在工作,但还没有正式发布,也没有官方更新站点(只有一些外部更新站点,从主干定期构建http://www.jgit.org/updates) 因此,现在使用Git的首选方式是命令行。

其他回答

Subversion非常容易使用。在过去的几年里,我从来没有发现任何问题或事情没有像预期的那样工作。此外,还有许多优秀的GUI工具,对SVN集成的支持也很大。

With Git you get a more flexible VCS. You can use it the same way like SVN with a remote repository where you commit all changes. But you can also use it mostly offline and only push the changes from time to time to the remote repository. But Git is more complex and has a steeper learning curve. I found myself in the first time committing to wrong branches, creating branches indirectly or get error messages with not much informations about the mistake and where I must search with Google to get better informations. Some easy things like substitution of markers ($Id$) doesn't work but GIT has a very flexible filtering and hook mechanism to merge own scripts and so you get all things you need and more but it needs more time and reading of the documentation ;)

如果您主要脱机使用本地存储库,那么如果本地机器上丢失了某些东西,则没有备份。使用SVN,您主要使用远程存储库,同时您的备份也在另一个服务器上… Git也可以以同样的方式工作,但这并不是Linus的主要目标,要有类似SVN2的东西。它是为Linux内核开发人员和分布式版本控制系统的需要而设计的。

Git比SVN好吗?只需要一些版本历史记录和备份机制的开发人员可以轻松地使用SVN。经常使用分支、同时测试更多版本或主要离线工作的开发人员可以从Git的特性中受益。有一些非常有用的特性,比如SVN中没有的存储特性,可以使工作更轻松。但另一方面,并非所有人都需要所有功能。所以我看不到SVN的死角。

Git需要一些更好的文档,错误报告必须更有帮助。而且现有的有用的gui也很少。这次我只找到了一个支持大多数Git特性的Linux GUI (Git -cola)。Eclipse集成正在工作,但还没有正式发布,也没有官方更新站点(只有一些外部更新站点,从主干定期构建http://www.jgit.org/updates) 因此,现在使用Git的首选方式是命令行。

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

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

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

其他的回答很好地解释了Git的核心特性(这些特性非常棒)。但是还有很多小方法可以让Git表现得更好,并帮助我的生活更加理智。以下是一些小细节:

Git has a 'clean' command. SVN desperately needs this command, considering how frequently it will dump extra files on your disk. Git has the 'bisect' command. It's nice. SVN creates .svn directories in every single folder (Git only creates one .git directory). Every script you write, and every grep you do, will need to be written to ignore these .svn directories. You also need an entire command ("svn export") just to get a sane copy of your files. In SVN, each file & folder can come from a different revision or branch. At first, it sounds nice to have this freedom. But what this actually means is that there is a million different ways for your local checkout to be completely screwed up. (for example, if "svn switch" fails halfway through, or if you enter a command wrong). And the worst part is: if you ever get into a situation where some of your files are coming from one place, and some of them from another, the "svn status" will tell you that everything is normal. You'll need to do "svn info" on each file/directory to discover how weird things are. If "git status" tells you that things are normal, then you can trust that things really are normal. You have to tell SVN whenever you move or delete something. Git will just figure it out. Ignore semantics are easier in Git. If you ignore a pattern (such as *.pyc), it will be ignored for all subdirectories. (But if you really want to ignore something for just one directory, you can). With SVN, it seems that there is no easy way to ignore a pattern across all subdirectories. Another item involving ignore files. Git makes it possible to have "private" ignore settings (using the file .git/info/exclude), which won't affect anyone else.

它是分布的。基准测试表明,它的速度要快得多(考虑到它的分布式性质,像diffs和log这样的操作都是本地的,所以在这种情况下,它当然要快得多),而且工作文件夹也更小(这仍然让我大吃一惊)。

当您使用subversion或任何其他客户端/服务器版本控制系统时,您实际上是通过签出版本在您的机器上创建工作副本。这代表了存储库外观的时间快照。通过更新更新工作副本,通过提交更新存储库。

使用分布式版本控制,您没有快照,而是拥有整个代码库。想要一个3个月大的版本吗?没问题,3个月前的版本还在你的电脑上。这不仅意味着速度更快,而且如果您与中央服务器断开连接,您仍然可以执行许多您习惯的操作。换句话说,您不仅拥有给定修订的快照,而且拥有整个代码库。

您可能认为Git会占用大量硬盘空间,但从我看到的几个基准测试来看,它实际上占用的空间更少。不要问我怎么做。我的意思是,它是由莱纳斯构建的,我猜他对文件系统略知一二。

Git并不比Subversion好。但也不是更糟。这是不一样的。

关键的区别在于它是去中心化的。想象一下你是一个在路上的开发人员,你在你的笔记本电脑上开发,你想要有源代码控制,这样你就可以回到3小时前。

使用Subversion时,您会遇到一个问题:SVN存储库可能位于您无法到达的位置(在您的公司中,并且您目前没有互联网),您无法提交。如果你想复制你的代码,你必须复制/粘贴它。

使用Git,您就不会遇到这个问题。您的本地副本是一个存储库,您可以提交它并获得源代码控制的所有好处。当您重新获得到主存储库的连接时,您可以针对它提交。

一开始看起来不错,但是要记住这种方法增加了复杂性。

Git似乎是“新的、闪亮的、酷的”东西。它绝对不坏(毕竟Linus为Linux内核开发写了它是有原因的),但是我觉得很多人只是因为它是新的并且是由Linus Torvalds写的,就跳上了“分布式源代码控制”这列火车,而不知道为什么/它是否更好。

Subversion有问题,但是Git、Mercurial、CVS、TFS等等也有问题。

编辑:所以这个答案现在已经有一年了,仍然获得了很多赞,所以我想我会添加更多的解释。在写这篇文章后的去年,Git获得了很多动力和支持,特别是在像GitHub这样的网站真正起飞之后。我现在同时使用Git和Subversion,我想分享一些个人见解。

First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "git init" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.

当你去中心化的时候,Git真的会发光。我家里有一台服务器,路上有一台笔记本电脑,SVN在这里根本不能很好地工作。使用SVN,如果我没有连接到存储库,我就不能进行本地源代码控制(是的,我知道SVK或复制回购的方法)。对于Git,这是默认模式。这是一个额外的命令(git commit在本地提交,而git push origin master将主分支推到名为“origin”的远程)。

如上所述:Git增加了复杂性。创建存储库的两种模式,签出vs克隆,提交vs推…您必须知道哪些命令在本地工作,哪些命令在“服务器”上工作(我假设大多数人仍然喜欢中央的“主存储库”)。

而且,工具仍然不够,至少在Windows上是这样。是的,有一个Visual Studio插件,但我仍然使用git bash和msysgit。

SVN的优点是学习起来简单得多:有您的存储库,所有针对它的更改,如果您知道如何创建、提交和签出,您就可以准备好,并可以在以后提取分支、更新等内容。

Git的优势在于,如果一些开发人员不总是连接到主存储库,它会更适合。而且,它比SVN快得多。据我所知,分支和合并支持要好得多(这是意料之中的,因为这是编写它的核心原因)。

这也解释了为什么它在互联网上获得了如此多的关注,因为Git非常适合开源项目:只需Fork它,将您的更改提交到您自己的Fork,然后让原始项目维护者提取您的更改。使用Git,这就可以了。真的,在Github上试试吧,太神奇了。

我还看到了Git-SVN网桥:中央存储库是一个Subversion repo,但开发人员在本地使用Git,网桥将他们的更改推到SVN。

但是即使有了这么长的补充,我仍然坚持我的核心信息:Git并没有更好或更差,它只是不同而已。如果你需要“离线源代码控制”,并愿意花一些额外的时间学习它,那就太棒了。但是如果您有一个严格集中的源代码控制,并且/或者因为您的同事不感兴趣而在第一时间努力引入源代码控制,那么SVN的简单性和出色的工具(至少在Windows上)就会脱颖而出。