我已经使用Subversion几年了,在使用SourceSafe之后 ,我只是喜欢Subversion。 结合TortoiseSVN ,我无法想象它会如何变得更好。

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

Git如何改进Subversion?

===============>>#1 票数:548 已采纳

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

关键的区别在于它是分散的。 想象一下,如果你是一名开发人员,你可以在笔记本电脑上进行开发,并希望拥有源代码控制,这样你就可以回到3个小时。

使用Subversion,您遇到了一个问题:SVN存储库可能位于您无法访问的位置(在您的公司中,目前您还没有Internet),您无法提交。 如果要复制代码,则必须逐字复制/粘贴它。

有了Git,你没有这个问题。 您的本地副本是一个存储库,您可以提交它并获得源代码管理的所有好处。 当您重新获得与主存储库的连接时,您可以对其进行提交。

这开始看起来很不错,但请记住这种方法增加的复杂性。

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

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

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

首先,Git在分散工作时起初可能会让人感到困惑。 什么是遥控器? 以及如何正确设置初始存储库? 一开始就出现了两个问题,特别是与SVN的简单“svnadmin创建”相比,Git的“git init”可以采用参数--bare和--shared这似乎是设置集中的“正确”方式库。 这是有原因的,但它增加了复杂性。 “checkout”命令的文档对于转换的人来说非常混乱 - “正确”的方式似乎是“git clone”,而“git checkout”似乎可以切换分支。

当你分散时,Git真的很棒。 我家里有一台服务器,路上有一台笔记本电脑,SVN在这里效果不好。 使用SVN,如果我没有连接到存储库,我就无法拥有本地源代码控制(是的,我知道SVK或者有关复制repo的方法)。 使用Git,无论如何这都是默认模式。 这是一个额外的命令(git commit在本地提交,而git push origin master将master分支推送到名为“origin”的远程)。

如上所述:Git增加了复杂性。 创建存储库,checkout与clone,commit与push的两种模式......你必须知道哪些命令在本地工作,哪些命令与“服务器”一起工作(我假设大多数人仍然喜欢中央“主存储库” )。

此外,至少在Windows上,工具仍然不足。 是的,有一个Visual Studio AddIn,但我仍然使用git bash和msysgit。

SVN的优势在于它更容易学习:如果您知道如何创建,提交和结帐,那么您的存储库,所有更改都会对您进行创建,提交和结帐,并且您已准备就绪,可以在以后进行分支,更新等操作。上。

如果某些开发人员并不总是连接到主存储库,那么Git的优势在于它更适合。 而且,它比SVN快得多。 从我所听到的情况来看,分支和合并支持要好得多(这是预期的,因为这些是编写它的核心原因)。

这也解释了为什么它在互联网上获得如此多的关注,因为Git非常适合开源项目:Just Fork it,将您的更改提交给您自己的Fork,然后让原始项目维护者提取您的更改。 有了Git,这才有效。 真的,在Github上尝试一下,这很神奇。

我还看到Git-SVN Bridges:中央存储库是一个Subversion存储库,但开发人员在本地使用Git,然后桥接器将其更改推送到SVN。

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

===============>>#2 票数:145

使用Git,您几乎可以在线下执行任何操作,因为每个人都有自己的存储库。

在分支之间建立分支和合并非常容易。

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

分叉一个项目,修改它,并继续合并来自HEAD分支的错误修正是微不足道的。

Git适用于Linux内核开发人员。 这意味着它真的很快(必须),并扩展到成千上万的贡献者。 Git也使用更少的空间(Mozilla存储库的空间减少了30倍)。

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

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

Git的缺点:

  • 学习起来要困难得多,因为Git有更多的概念和更多的命令。
  • 修订版没有像subversion那样的版本号
  • 许多Git命令都很神秘,错误消息对用户不友好
  • 它缺乏一个好的GUI(如伟大的TortoiseSVN

===============>>#3 票数:110

其他答案在解释Git的核心功能方面做得很好(很棒)。 但也有很多方法让Git表现得更好,并有助于让我的生活更加健全。 以下是一些小事:

  1. Git有一个'干净'命令。 SVN迫切需要这个命令,考虑它会在磁盘上转储额外文件的频率。
  2. Git有'bisect'命令。 这真好。
  3. SVN在每个文件夹中创建.svn目录(Git只创建一个 .git目录)。 您编写的每个脚本以及您执行的每个grep都需要编写以忽略这些.svn目录。 您还需要一个完整的命令(“svn export”)才能获得文件的合理副本。
  4. 在SVN中,每个文件和文件夹可以来自不同的修订版或分支。 起初,拥有这种自由听起来不错。 但这实际上意味着有一百万种不同的方式让您的本地结账完全搞砸了。 (例如,如果“svn switch”中途失败,或者输入的命令错误)。 最糟糕的是:如果你遇到某些文件来自一个地方,而其中一些来自另一个地方的情况,“svn状态”会告诉你一切正常。 您需要在每个文件/目录上执行“svn info”以发现奇怪的事情。 如果“git status”告诉你事情是正常的,那么你可以相信事情是正常的。
  5. 无论何时移动或删除某些内容,都必须告诉SVN。 Git会想出来的。
  6. 在Git中忽略语义更容易。 如果忽略模式(例如* .pyc),则将忽略所有子目录。 (但如果你真的想忽略一个目录的东西,你可以)。 使用SVN,似乎没有简单的方法可以忽略所有子目录中的模式。
  7. 涉及忽略文件的另一项。 Git可以使用“私有”忽略设置(使用文件.git / info / exclude),这不会影响其他任何人。

===============>>#4 票数:56

为什么Git比X更好 ”概述了Git与其他SCM的各种优缺点。

简述:

  • Git跟踪内容而不是文件
  • 分支很轻 ,合并很容易 ,我的意思很简单
  • 它是分布式的,基本上每个存储库都是一个分支。 在我看来,与Subversion相比,并发和协作开发要容易得多。 它还使离线开发成为可能。
  • 没有强加任何工作流程 ,如上面链接的网站所示 ,Git可以实现许多工作流程。 Subversion风格的工作流程很容易模仿。
  • Git存储库的文件大小比Subversion存储库小得多 只有一个“.git”目录,而不是几十个“.svn”存储库(注意Subversion 1.7和更高版本现在使用像Git这样的单个目录 。)
  • 暂存区域非常棒,它允许您查看要提交的更改,提交部分更改以及执行各种其他操作。
  • 当你进行“混乱”开发时, 存储是非常宝贵的,或者只是想在你还在处理其他东西时(在不同的分支上)修复bug。
  • 您可以重写历史记录 ,这对于准备补丁集和修复错误非常有用( 发布提交之前
  • ...和更大量

有一些缺点:

  • 目前还没有很多优秀的GUI。 这是新的,Subversion已经存在了很长时间,所以这很自然,因为开发中有一些接口。 一些好的包括TortoiseGitMac的GitHub
  • 目前无法进行部分检查/克隆存储库(我读到它正处于开发阶段)。 但是,有子模块支持。 Git 1.7+支持稀疏检出
  • 它可能更难学,即使我没有发现这种情况(大约一年前)。 Git最近改进了它的界面并且非常用户友好。

在最简单的用法中,Subversion和Git几乎相同。 两者之间没有太大区别:

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

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

Git真正闪耀的地方是分支并与其他人合作。

===============>>#5 票数:54

Google Tech Talk:Linus Torvalds on git

http://www.youtube.com/watch?v=4XpnKHJAok8

Git Wiki的比较页面

http://git.or.cz/gitwiki/GitSvnComparsion

===============>>#6 票数:26

好吧,它是分发的。 基准测试表明它的速度相当快(鉴于其分布式特性,差异和日志等操作都是本地的,因此在这种情况下它的速度非常快),工作文件夹更小(这仍然让我感到震惊)。

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

使用分布式版本控制,您没有快照,而是整个代码库。 想要与3个月大的版本做差异? 没问题,3个月大的版本仍然在您的计算机上。 这不仅意味着事情变得更快,而且如果您与中央服务器断开连接,您仍然可以执行您习惯的许多操作。 换句话说,您不仅拥有给定修订的快照,而且拥有整个代码库。

你认为Git会在你的硬盘上占用一大堆空间,但是从我看过的几个基准测试中,它实际上需要更少。 别问我怎么样。 我的意思是,它是由Linus构建的,他对文件系统知道一两件事。

===============>>#7 票数:22

我喜欢DVCS的要点是:

  1. 你可以犯下破碎的东西。 这没关系,因为在您发布之前,其他人不会看到它们。 发布时间与提交时间不同。
  2. 因此,您可以更频繁地提交。
  3. 您可以合并完整的功能。 这个功能将有自己的分支。 此分支的所有提交都与此功能相关。 你可以使用CVCS,但DVCS是默认值。
  4. 您可以搜索历史记录(查找功能何时更改)
  5. 如果某人搞砸了主存储库,您可以撤消拉取,您不需要修复错误。 只需清除合并。
  6. 当你需要任何目录中的源代码控制时,请执行:git init。 你可以提交,撤消更改等...
  7. 它很快(即使在Windows上)

一个相对较大的项目的主要原因是由第3点创建的改进的沟通。其他是很好的奖金。

===============>>#8 票数:15

有趣的是:我在Subversion Repos中托管项目,但是通过Git Clone命令访问它们。

请阅读Google代码项目中使用Git开发

尽管Google Code本身就是Subversion,但您可以在开发过程中轻松使用Git。 搜索“git svn”表明这种做法很普遍,我们也鼓励你尝试一下。

在Svn存储库上使用Git给我带来的好处:

  1. 我可以分布在几台机器上工作,提交和拉动它们
  2. 我有一个中央 backup/public svn存储库供其他人查看
  3. 他们可以自由地使用Git

===============>>#9 票数:11

这里的所有答案都是预期的,以程序员为中心,但是如果您的公司在源代码之外使用修订控制会发生什么? 有许多文档不是源代码,它们受益于版本控制,应该靠近代码而不是另一个CMS。 大多数程序员不是孤立地工作 - 我们作为团队的一部分为公司工作。

考虑到这一点,比较Subversion和git之间在客户端工具和培训中的易用性。 我看不到任何分布式版本控制系统将更容易使用或向非程序员解释的场景。 我很想被证明是错的,因为那样我就能够评估git,并且实际上希望它能够被需要版本控制但不是程序员的人所接受。

即便如此,如果管理层要求我们为什么要从集中式转发到分布式版本控制系统,我很难给出一个诚实的答案,因为我们不需要它。

免责声明:我很早就开始对Subversion感兴趣(大约在第29节),所以很明显我有偏见,但我从那时起为之工作的公司都受益于我的热情,因为我鼓励并支持它的使用。 我怀疑这是大多数软件公司的情况。 有这么多程序员跳上git的潮流,我想知道有多少公司会错过在源代码之外使用版本控制的好处? 即使您拥有针对不同团队的单独系统,您也会错过一些好处,例如(统一)问题跟踪集成,同时增加维护,硬件和培训要求。

===============>>#10 票数:9

Subversion仍然是一个更常用的版本控制系统,这意味着它有更好的工具支持。 你会发现几乎所有IDE都有成熟的SVN插件,并且有很好的资源管理器扩展(如TurtoiseSVN)。 除此之外,我将不得不同意迈克尔 :Git并不比Subversion更好或更差,它是不同的。

===============>>#11 票数:8

关于SubVersion让我烦恼的一件事是它将自己的文件夹放在项目的每个目录中,而git只将一个放在根目录中。 这不是什么大不了的事情,但是像这样的小事情加起来。

当然,SubVersion有Tortoise,[通常]非常好。

===============>>#12 票数:8

关于Subversion / GIT的David Richards WANdisco博客

GIT的出现带来了一系列DVCS原教旨主义者 - “Gitterons” - 认为GIT以外的任何东西都是垃圾。 Gitterons似乎认为软件工程在他们自己的岛上发生,并且经常忘记大多数组织不专门聘请高级软件工程师。 这没关系,但不是其他市场的想法,我很乐意证明这一点:GIT,最后看起来不到3%的市场,而Subversion在500万用户和大约一半的用户整体市场。

我们看到的问题是Gitterons在Subversion上射击(便宜)。 像Subversion这样的推文是如此[缓慢/蹩脚/限制/闻不到好/以有趣的方式看着我]现在我有GIT和[一切都在我的生活中工作/我的妻子怀孕/我有一个女朋友后30年的尝试/我赢得六次在二十一点桌上运行]。 你得到了照片。

===============>>#13 票数:7

Git也使分支和合并变得非常简单。 Subversion 1.5刚刚添加了合并跟踪,但Git仍然更好。 使用Git分支非常快速且便宜。 它使得为每个新功能创建分支更加可行。 与Subversion相比,Oh和Git存储库在存储空间方面非常有效。

===============>>#14 票数:6

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

===============>>#15 票数:6

这完全取决于易用性/做某事所需的步骤。

如果我在我的PC /笔记本电脑上开发一个项目,git会更好,因为设置和使用起来要容易得多。 您不需要服务器,并且在进行合并时不需要继续键入存储库URL。

如果它只是2个人,我会说git也更容易,因为你可以从彼此推拉。

一旦你超越了它,我就会去颠覆,因为那时你需要设置一个“专用”服务器或位置。

您可以使用git和SVN一样执行此操作,但是需要执行额外的步骤来与中央服务器同步,因此git的好处超过了。 在SVN中你只需要提交。 在git中你必须git commit,然后git push。 额外的步骤很烦人,因为你最终做了这么多。

SVN还有更好的GUI工具的好处,但是git生态系统似乎很快就会迎头赶上,所以从长远来看我不会担心这个问题。

===============>>#16 票数:5

我喜欢Git,因为它实际上有助于沟通开发人员与大中型团队的开发人员合作。 作为分布式版本控制系统,通过其推/拉系统,它可以帮助开发人员创建源代码生态系统,帮助管理在单个项目上工作的大量开发人员。

例如,假设你信任5个开发人员,只从他们的存储库中提取代码。 每个开发人员都有自己的信任网络,从中提取代码。 因此,开发基于开发人员的信任结构,其中代码责任在开发社区之间共享。

当然,这里还有其他答案中提到的其他好处。

===============>>#17 票数:5

Git和DVCS一般非常适合开发人员彼此独立编码,因为每个人都有自己的分支。 但是,如果您需要从其他人那里进行更改,那么她必须承诺使用当地的回购,然后她必须将该变更集推送给您,否则您必须将其从她手中取出。

我自己的推理也让我觉得如果你做集中发布之类的事情,DVCS会让QA和发布管理变得更难。 有人必须负责从其他人的存储库执行推/拉,解决在之前的初始提交时已经解决的任何冲突,然后进行构建,然后让所有其他开发人员重新同步他们的存储库。

当然,所有这些都可以通过人类过程来解决; DVCS刚刚打破了集中版本控制修复的东西,以提供一些新的便利。

===============>>#18 票数:4

一些答案已经提到了这些,但我想明确指出2点:

1)进行选择性提交的能力(例如, git add --patch )。 如果您的工作目录包含多个不属于同一逻辑更改的更改,Git可以非常轻松地进行仅包含部分更改的提交。 使用Subversion很难。

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

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

===============>>#19 票数:4

我认为Subversion很好..直到你开始合并..或做任何复杂的事情......或者做任何事情Subversion认为是复杂的(比如做查询以找出哪些分支与特定文件混淆, 实际发生了变化,检测复制和粘贴等)...

我不同意获胜的答案,说GIT的主要好处是离线工作 - 它肯定是有用的,但它更像是我的用例的额外功能。 SVK也可以离线工作,对我来说仍然没有问题可以投入我的学习时间。

它只是它非常强大和快速,并且在习惯了概念之后 - 非常有用(是的,在这个意义上:用户友好)。

有关合并故事的更多详细信息,请参阅: 使用git-svn(或类似)* just *来帮助svn合并?

===============>>#20 票数:3

我非常希望能够在Git中管理我的源代码的本地分支,而不会混淆中央存储库的水。 在许多情况下,我将从Subversion服务器检出代码并运行本地Git存储库,以便能够执行此操作。 初始化Git存储库并不会在任何地方使用一堆恼人的.svn文件夹污染文件系统,这也很棒。

至于Windows工具支持,TortoiseGit非常好地处理基础知识,但我仍然更喜欢命令行,除非我想查看日志。 我非常喜欢Tortoise {Git | SVN}在阅读提交日志时提供帮助的方式。

===============>>#21 票数:3

由于它不需要经常与中央服务器通信,因此几乎每个命令都在不到一秒的时间内运行(显然git push / pull / fetch因为必须启动SSH连接而变慢)。 分支更容易(一个简单的分支命令,一个简单的命令合并)

===============>>#22 票数:3

这是一个错误的问题。 很容易专注于git的瑕疵并制定一个关于为什么颠覆表面上更好的论据,至少对于一些用例来说。 事实上,git最初被设计为低级版本控制构造集,并且具有巴洛克式的linux开发人员界面,使得神圣战争更容易获得牵引力和合法性。 Git的支持者为鼓提供了数以百计的工作流程优势,而这些优势让人觉得不必要。 很快,整个辩论被构建为集中式和分布式,这符合企业svn工具社区的利益。 这些公司通常发表有关颠覆在企业中的优势的最有说服力的文章,取决于git的不安全感以及svn企业为其产品的长期成功做好准备。

但问题在于: Subversion是一个架构的死胡同

虽然你可以很容易地使用git并构建一个集中的subversion替换,尽管svn已经超过两倍,但是从来没有能够获得基本的合并跟踪工作,就像在git中一样。 一个基本原因是设计决策使分支与目录相同。 我不知道他们为什么这么做,这肯定会使部分结账非常简单。 不幸的是,这也使得无法正确追踪历史。 现在显然你应该使用subversion存储库布局约定来将分支与常规目录分开,并且svn使用一些启发式方法使事情适用于日常用例。 但所有这些只是针对一个非常糟糕和有限的低级别设计决策。 能够执行存储库方面的差异(而不是目录方式差异)是版本控制系统的基本和关键功能,并且极大地简化了内部,使得在其上构建更智能和有用的功能成为可能。 您可以看到延伸颠覆所付出的努力量,然而在合并解析等基本操作方面,它与当前现代VCS的距离有多远。

现在,对于那些仍然相信Subversion在可预见的未来足够好的人来说,这是我心扉和不可知的建议:

Subversion永远不会赶上从RCS和CVS的错误中吸取教训的新版VCS; 除非他们从头开始重新整理存储库模型,否则技术上是不可能的,但那么它真的不是真的吗? 无论你认为自己没有多少现代VCS的能力,你的无知都无法保护你免受Subversion的陷阱,其中许多是在其他系统中不可能或很容易解决的情况。

极为罕见的是,解决方案的技术劣势与svn一样清晰,当然我永远不会对win-vs-linux或emacs-vs-vi发表这样的意见,但在这种情况下它是如此清晰度和源代码控制是开发人员库中的一个基本工具,我觉得必须明确说明。 无论出于组织原因要求使用svn,我都恳请所有svn用户不要让他们的逻辑思维构造错误的信念,即更现代的VCS只对大型开源项目有用。 无论您的开发工作的性质如何,如果您是程序员,如果您学习如何使用设计更好的VCS,无论是Git,Mercurial,Darcs还是其他许多人,您将成为更有效的程序员。

===============>>#23 票数:2

Subversion很容易使用。 我在过去几年里从来没有发现过一个问题或某些事情没有按预期发挥作用。 还有许多优秀的GUI工具,对SVN集成的支持很大。

使用Git,您可以获得更灵活的VCS。 您可以像使用SVN一样使用它,并使用远程存储库提交所有更改。 但是您也可以在离线时使用它,并且只是不时地将更改推送到远程存储库。 但Git更复杂,学习曲线更陡峭。 我发现自己第一次犯错误的分支,间接创建分支或获取错误消息,但没有太多关于错误的信息以及我必须在Google搜索以获得更好的信息。 一些简单的事情,如替换标记($ Id $)不起作用,但GIT有一个非常灵活的过滤和钩子机制来合并自己的脚本,所以你得到你需要的所有东西和更多,但它需要更多的时间和阅读文档;)

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

SVT比SVN更好吗? 只需要一些版本历史和备份机制的开发人员可以通过SVN轻松生活。 经常与分支机构合作,同时测试更多版本或大部分离线工作的开发人员都可以从Git的功能中受益。 有一些非常有用的功能,如SVN没有找到的存储,可以使生活更轻松。 但另一方面并非所有人都需要所有功能。 所以我看不到SVN的死者。

Git需要一些更好的文档,错误报告必须更有帮助。 现有的有用GUI也很少。 这次我只找到了1个Linux的GUI,支持大多数Git功能(git-cola)。 Eclipse集成正在运行,但它没有正式发布,并且没有官方更新站点(只有一些外部更新站点,其中包含来自主干的周期性构建http://www.jgit.org/updates )所以今天最喜欢使用Git的方式是命令行。

===============>>#24 票数:2

SourceGear的Eric Sink撰写了一系列关于分布式和非分布式版本控制系统之间差异的文章。 他比较了最流行的版本控制系统的优缺点。 非常有趣的阅读。
文章可以在他的博客www.ericsink.com上找到:

===============>>#25 票数:2

对于寻找优秀Git GUI的人来说, Syntevo SmartGit可能是一个很好的解决方案。 它的专有但免费用于非商业用途,可以在Windows / Mac / Linux上运行,甚至可以使用某种git-svn桥支持SVN。

===============>>#26 票数:1

首先,并发版本控制似乎是一个容易解决的问题。 它根本不是。 无论如何...

SVN非常不直观。 Git更糟糕。 [sarcastic-speculation]这可能是因为开发人员喜欢并发版本控制等硬问题,对制作良好的UI没有太大兴趣。 [/讽刺投机]

SVN支持者认为他们不需要分布式版本控制系统。 我也这么认为。 但是现在我们只使用Git,我是一个信徒。 现在版本控制适用于我和团队/项目,而不仅仅是为项目工作。 当我需要一个分支时,我分支。 有时它是一个在服务器上有相应分支的分支,有时它不会。 更不用说我将要研究的所有其他优点(部分归功于现代版本控制系统的神秘和荒谬的缺乏UI)。

===============>>#27 票数:1

现在,Windows中的Git得到了很好的支持。

查看GitExtensions = http://code.google.com/p/gitextensions/

以及更好的Windows Git体验手册。

===============>>#28 票数:1

http://subversion.wandisco.com/component/content/article/1/40.html

我认为在开发人员中说SVN对比是相当安全的。 Git论证已经持续了一段时间,每个人都有自己的观点,哪个更好。 在2010年及以后的Subversion网络研讨会期间,甚至提出了这些问题。

我们的开源总监和Subversion公司总裁Hyrum Wright谈到了Subversion和Git以及其他分布式版本控制系统(DVCS)之间的差异。

他还谈到了Subversion即将发生的变化,例如下一代工作副本(WC-NG),他认为这将导致许多Git用户转换回Subversion。

观看他的视频,通过评论此博客或在我们的论坛中发帖,让我们知道您的想法。 注册很简单,只需要一点时间!

===============>>#29 票数:1

我最近一直住在Git的土地上,我喜欢它用于个人项目,但是考虑到工作人员所需要的改变,我无法将工作项目改为Subversion而没有任何紧迫的好处。 此外,我们内部运行的最大项目非常依赖于svn:externals ,从我到目前为止看来,它在Git中不能很好地和无缝地工作。

===============>>#30 票数:1

为什么我认为Subversion比Git更好(至少对于我工作的项目),主要是因为它的可用性和更简单的工作流程:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

  ask by community wiki translate from so

未解决问题?本站智能推荐: