我已经使用Subversion很多年了,在使用SourceSafe之后,我爱上了Subversion。结合TortoiseSVN,我真的无法想象它还能有什么更好的。
然而,越来越多的开发人员声称Subversion存在问题,我们应该转向新的分布式版本控制系统,比如Git。
Git如何改进Subversion?
我已经使用Subversion很多年了,在使用SourceSafe之后,我爱上了Subversion。结合TortoiseSVN,我真的无法想象它还能有什么更好的。
然而,越来越多的开发人员声称Subversion存在问题,我们应该转向新的分布式版本控制系统,比如Git。
Git如何改进Subversion?
当前回答
我认为Subversion很好。直到你开始合并…或者做任何复杂的事情。或者做任何Subversion认为复杂的事情(比如查询哪些分支弄乱了特定的文件,更改实际上来自哪里,检测复制和粘贴,等等)…
我不同意获胜的答案,我认为GIT的主要好处是离线工作——它当然有用,但它更像是我的用例的额外功能。SVK也可以离线工作,对我来说,把我的学习时间投入到哪一个是没有问题的)。
只是它非常强大、快速,而且——在习惯了这些概念之后——非常有用(是的,在这个意义上:用户友好)。
有关合并故事的更多细节,请参见: 使用git-svn(或类似)*只是*帮助svn合并?
其他回答
有趣的是: 我在Subversion Repos中托管项目,但是通过Git Clone命令访问它们。
请阅读在谷歌代码项目中使用Git进行开发
虽然谷歌代码原生说话 Subversion,可以轻松使用Git 在开发过程中。搜索“git” Svn建议这种做法是正确的 广泛传播,我们也鼓励你 用它来做实验。
在Svn存储库上使用Git给我带来了好处:
我可以分配到几个 机器,承诺和从 对他们来说 我有一个中央备份/公共svn存储库供其他人检查 他们可以自由地使用Git
一些回答已经提到了这些问题,但我想明确说明两点:
1)有选择性提交的能力(例如,git add——patch)。如果您的工作目录包含多个不属于同一逻辑更改的更改,Git可以很容易地提交只包含部分更改的提交。对于Subversion,这是很困难的。
2)在不公开更改的情况下提交的能力。在Subversion中,任何提交都是立即公开的,因此是不可撤销的。这极大地限制了开发人员“尽早提交,经常提交”的能力。
Git不仅仅是一个VCS;它也是一个开发补丁的工具。Subversion只是一个VCS。
来自SourceGear的Eric Sink写了一系列关于分布式和非分布式版本控制系统之间区别的文章。他比较了最流行的版本控制系统的优缺点。非常有趣的读物。 文章可以在他的博客www.ericsink.com上找到:
阅读差异 Git是版本控制工具中的C Git缺乏对不变性和DVCS最佳实践的尊重 DVCS和dag,第1部分 DVCS和dag,第2部分 DVCS和Bug跟踪 合并历史,dag和Darcs Git为什么这么快? Mercurial, Subversion和Wesley Snipes
Windows中的Git现在得到了很好的支持。
查看GitExtensions = http://code.google.com/p/gitextensions/
以及更好的Windows Git体验的手册。
我非常喜欢能够在Git中管理源代码的本地分支,而不会混淆中央存储库的水。在许多情况下,我将从Subversion服务器签出代码并运行本地Git存储库,只是为了能够做到这一点。初始化Git存储库不会因为到处都是烦人的.svn文件夹而污染文件系统,这一点也很棒。
至于Windows工具的支持,TortoiseGit处理基本的很好,但我仍然喜欢命令行,除非我想查看日志。我真的很喜欢Tortoise{Git|SVN}在读取提交日志时的帮助方式。