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

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

Git如何改进Subversion?


当前回答

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

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

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

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

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

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

其他回答

“为什么Git比X好”概述了Git相对于其他scm的各种优缺点。

简要:

Git tracks content rather than files Branches are lightweight and merging is easy, and I mean really easy. It's distributed, basically every repository is a branch. It's much easier to develop concurrently and collaboratively than with Subversion, in my opinion. It also makes offline development possible. It doesn't impose any workflow, as seen on the above linked website, there are many workflows possible with Git. A Subversion-style workflow is easily mimicked. Git repositories are much smaller in file size than Subversion repositories. There's only one ".git" directory, as opposed to dozens of ".svn" repositories (note Subversion 1.7 and higher now uses a single directory like Git.) The staging area is awesome, it allows you to see the changes you will commit, commit partial changes and do various other stuff. Stashing is invaluable when you do "chaotic" development, or simply want to fix a bug while you're still working on something else (on a different branch). You can rewrite history, which is great for preparing patch sets and fixing your mistakes (before you publish the commits) … and a lot more.

有一些缺点:

There aren't many good GUIs for it yet. It's new and Subversion has been around for a lot longer, so this is natural as there are a few interfaces in development. Some good ones include TortoiseGit and GitHub for Mac. Partial checkouts/clones of repositories are not possible at the moment (I read that it's in development). However, there is submodule support. Git 1.7+ supports sparse checkouts. It might be harder to learn, even though I did not find this to be the case (about a year ago). Git has recently improved its interface and is quite user friendly.

在最简单的用法中,Subversion和Git是差不多的。两者之间没有太大区别:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

and

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Git真正的亮点在于分支和与其他人一起工作。

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

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

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

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

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

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

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

Easy Git有一个很好的页面,比较了Git和SVN的实际使用情况,这将让你了解Git可以做什么(或更容易做什么)。(从技术上讲,这是基于Easy Git的,它是Git之上的轻量级包装器。)

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

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