我已经使用Subversion很多年了,在使用SourceSafe之后,我爱上了Subversion。结合TortoiseSVN,我真的无法想象它还能有什么更好的。
然而,越来越多的开发人员声称Subversion存在问题,我们应该转向新的分布式版本控制系统,比如Git。
Git如何改进Subversion?
我已经使用Subversion很多年了,在使用SourceSafe之后,我爱上了Subversion。结合TortoiseSVN,我真的无法想象它还能有什么更好的。
然而,越来越多的开发人员声称Subversion存在问题,我们应该转向新的分布式版本控制系统,比如Git。
Git如何改进Subversion?
当前回答
对于那些正在寻找一个好的Git GUI的人来说,Syntevo SmartGit可能是一个很好的解决方案。它是私有的,但对非商业用途是免费的,可以在Windows/Mac/Linux上运行,我认为甚至可以使用某种git-svn网桥来支持SVN。
其他回答
我非常喜欢能够在Git中管理源代码的本地分支,而不会混淆中央存储库的水。在许多情况下,我将从Subversion服务器签出代码并运行本地Git存储库,只是为了能够做到这一点。初始化Git存储库不会因为到处都是烦人的.svn文件夹而污染文件系统,这一点也很棒。
至于Windows工具的支持,TortoiseGit处理基本的很好,但我仍然喜欢命令行,除非我想查看日志。我真的很喜欢Tortoise{Git|SVN}在读取提交日志时的帮助方式。
Git和DVCS通常都非常适合于独立编写大量代码的开发人员,因为每个人都有自己的分支。但是,如果您需要从其他人那里进行更改,她必须提交给她的本地回购,然后她必须将该更改集推给您,或者您必须从她那里获取更改集。
我自己的推理也让我认为,如果你做集中发布之类的事情,DVCS会让QA和发布管理变得更加困难。必须有人负责从其他人的存储库中进行推送/拉取,解决任何在最初提交时就可以解决的冲突,然后进行构建,然后让所有其他开发人员重新同步他们的回购。
当然,所有这些都可以通过人工流程来解决;DVCS只是破坏了一些由集中式版本控制修复的东西,以便提供一些新的便利。
“为什么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会占用大量硬盘空间,但从我看到的几个基准测试来看,它实际上占用的空间更少。不要问我怎么做。我的意思是,它是由莱纳斯构建的,我猜他对文件系统略知一二。
有趣的是: 我在Subversion Repos中托管项目,但是通过Git Clone命令访问它们。
请阅读在谷歌代码项目中使用Git进行开发
虽然谷歌代码原生说话 Subversion,可以轻松使用Git 在开发过程中。搜索“git” Svn建议这种做法是正确的 广泛传播,我们也鼓励你 用它来做实验。
在Svn存储库上使用Git给我带来了好处:
我可以分配到几个 机器,承诺和从 对他们来说 我有一个中央备份/公共svn存储库供其他人检查 他们可以自由地使用Git