为什么Git比Subversion更好？

我已经使用了Subversion几年，在使用SourceSafe之后 ，我喜欢Subversion。 结合TortoiseSVN ，我真的无法想象它会如何更好。

然而越来越多的开发者声称Subversion有问题，我们应该转向分布式版本控制系统的新品种，比如Git 。

Git如何改进Subversion？

Answer 1

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

关键的区别是它是分散的。 想象一下，你是一名开发人员，在笔记本电脑上开发，并且希望拥有源代码控制，以便能够返回3小时。

使用Subversion，你有一个问题：SVN仓库可能在一个你无法访问的位置（在你的公司，而你目前没有互联网），你不能提交。 如果你想复制你的代码，你必须从字面上复制/粘贴它。

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

这看起来不错，但要记住这种方法的复杂性。

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

Subversion有问题，但Git，Mercurial，CVS，TFS或其他。

编辑：所以这个答案现在是一岁，仍然产生许多upvotes，所以我想我会添加更多的解释。 在写这篇文章的最后一年，Git获得了很多动力和支持，尤其是在GitHub这样的网站真正起飞的时候。 我现在正在使用Git和Subversion，我想分享一些个人见解。

首先，Git在分散工作的时候可能会非常混乱。 什么是遥控器？ 以及如何正确设置初始仓库？ 是一开始就提出的两个问题，尤其是与SVN简单的“svnadmin create”相比，Git的“git init”可以采用参数–bare和–shared，这似乎是“正确”的方式来build立一个集中库。 这是有原因的，但增加了复杂性。 “checkout”命令的文档对于转换的人来说是非常混乱的 – “正确的”方式似乎是“git clone”，而“git checkout”似乎改变了分支。

Git当你分散的时候真的很闪耀。 我在家里有一台服务器，路上有一台笔记本电脑，而SVN在这里根本不起作用。 使用SVN，如果我没有连接到存储库（是的，我知道关于SVK或复制回购的方法），我不能有本地源代码pipe理。 使用Git，无论如何，这是默认模式。 这是一个额外的命令，虽然（git提交本地提交，而git推送起源主推动主分支到远程名为“起源”）。

如上所述：Git增加了复杂性。 两种模式创build存储库，结帐与克隆，提交与推…你必须知道哪些命令在本地工作，哪些与“服务器”工作（我假设大多数人仍然像一个中央“主存储库” ）。

另外，工具仍然不足，至less在Windows上。 是的，有一个Visual Studio AddIn，但我仍然使用msysgit的git bash。

SVN的优点是学习起来要简单得多：如果你知道如何创build，提交和签出，那么就有你的存储库和所有的改变，你可以随时去分支，更新等等。上。

Git的优点是，如果一些开发人员并不总是连接到主存储库，那么它就更适合。 而且，它比SVN快得多。 而且从我所听到的，分支和合并的支持要好得多（这是可以预料的，因为这是它写的核心原因）。

这也解释了为什么它会在互联网上获得如此多的热门话题，因为Git完全适用于开源项目：只需分叉它，将自己的修改提交到自己的Fork，然后让原始项目维护人员进行修改。 与Git，这只是工作。 真的，在Github上试试吧，这很神奇。

我还看到的是Git-SVN网桥：中央存储库是一个Subversion的回购站，但开发人员在本地使用Git，然后网桥将其更改推送到SVN。

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

Answer 2

有了Git，你几乎可以离线执行任何事情，因为每个人都有自己的存储库。

在分支之间进行分支和合并非常简单。

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

这是微不足道的分叉项目，修改它，仍然保持合并在HEAD分支的错误修正。

Git适用于Linux内核开发人员。 这意味着它真的很快（它必须是），并扩展到成千上万的贡献者。 Git也使用较less的空间（Mozilla存储库的空间减less多达30倍）。

Git非常灵活，非常有TIMTOWTDI（有多种方法可以做到这一点）。 你可以使用任何你想要的工作stream程，而Git会支持它。

最后，有一个GitHub ，一个用来托pipe你的Git仓库的好地方。

Git的缺点：

• 学习起来要困难得多，因为Git有更多的概念和更多的命令。
• 修订版本没有像在Subversion中那样的版本号
• 许多Git命令是神秘的，错误消息是非常不友好的用户
• 它缺less一个好的GUI（如伟大的TortoiseSVN ）

Answer 3

其他答案已经做了很好的解释Git的核心function（这是伟大的）。 但是也有很多小方法让Git的performance更好，有助于保持我的生活更加健康。 以下是一些小的事情：

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

Answer 4

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

简述：

• Git跟踪内容而不是文件
• 分支是轻量级的 ，合并很容易 ，我的意思是非常简单 。
• 它是分布式的，基本上每个存储库都是一个分支。 在我看来，与Subversion相比，并发和协作开发要容易得多。 这也使离线开发成为可能。
• 它不强加任何工作stream程 ，正如在上面链接的网站上看到的 ，Git有很多可能的工作stream程。 Subversion风格的工作stream程很容易被模仿。
• Git仓库的文件大小比Subversion仓库小得多 。 只有一个“.git”目录，而不是几十个“.svn”存储库（注意，Subversion 1.7和更高版本现在使用一个像Git这样的目录 ）。
• 暂存区是非常棒的，它可以让你看到你将要提交的更改，提交部分更改并执行其他各种操作。
• 当您进行“混乱”的开发时， 隐藏是无价之宝，或者只是想要在修复某个错误时（在不同的分支上）修复一个错误。
• 您可以重写历史logging ，这非常适合准备补丁集并修复错误（ 在发布提交之前 ）
• …还有更多。

有一些缺点：

• 目前还没有很多好的GUI。 这是新的，Subversion已经存在了很长时间，所以这是很自然的，因为在开发中有一些接口。 一些好的包括Mac版的 TortoiseGit和GitHub 。
• 部分检出/克隆库是不可能的（我读它正在开发中）。 但是，有子模块的支持。 Git 1.7+支持稀疏检出 。
• 虽然我不觉得这是事实（大约一年前），但是学习起来可能会更困难。 Git最近改进了它的界面，并且相当用户友好。

在最简单的用法中，Subversion和Git几乎是一样的。 没有太大的区别：

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

和

 git clone [e-mail]:foo/bar.git cd bar # edit git commit -a -m "foo" git push 

Git真正闪耀的地方在于与别人分道扬</s>。

Answer 5

Google Tech Talk：git上的Linus Torvalds

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

Git Wiki的比较页面

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

Answer 6

那么，它是分布式的。 基准testing表明它速度相当快（考虑到它的分布式特性，差异和日志等操作都是本地的，所以在这种情况下，速度更快），而工作文件夹更小（这仍然让我感到震惊）。

当你在Subversion或者任何其他的客户/服务器版本控制系统上工作时，你通过签出修订版本来在你的机器上创build工作副本。 这代表了仓库看起来像什么时候的快照。 你通过更新来更新你的工作副本，并且你通过提交更新版本库。

使用分布式版本控制，您没有快照，而是整个代码库。 想与3个月大的版本做差异？ 没问题，3个月大的版本仍然在你的电脑上。 这不仅意味着事情会更快，但是如果您从中央服务器断开连接，您仍然可以执行许多您习惯的操作。 换句话说，你不只是给定修订版的快照，而是整个代码库。

你会认为Git会在你的硬盘上占用一堆空间，但是从我看到的一些基准testing中，它实际上花费的更less。 不要问我如何。 我的意思是，它是由Linusbuild立的，他知道我猜想的文件系统有一两件事。

Answer 7

我喜欢DVCS的主要观点是：

1. 你可以犯下破碎的东西。 这并不重要，因为其他人在你发表之前不会看到他们。 发布时间不同于提交时间。
2. 正因为如此，你可以更经常地提交。
3. 您可以合并完整的function。 这个function将会有自己的分支。 此分支的所有提交将与此function相关。 你可以用CVCS来完成，但是DVCS是默认的。
4. 你可以search你的历史（查找function改变时）
5. 如果有人搞砸了主存储库，你可以撤销拉，你不需要修复错误。 只要清除合并。
6. 当你需要在任何目录下的源代码控制时：git init。 你可以提交，撤消更改等
7. 它很快（甚至在Windows上）

一个比较大的项目的主要原因是由点3创造的改善的沟通。其他人是好的奖金。

Answer 8

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

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

虽然谷歌代码本身就说Subversion，但是在开发过程中可以很容易的使用Git。 search“git svn”表明这种做法非常普遍，我们也鼓励你去尝试一下。

在Svn Repository上使用Git给我带来好处：

1. 我可以在几台机器上工作，承诺和从他们拉
2. 我有一个中央 backup/public svn库供他人检查
3. 而且他们可以自由地使用Git

Answer 9

所有的答案都如预期的那样，程序员是中心的，但是如果你的公司使用源代码之外的版本控制，会发生什么？ 有许多源代码不受版本控制的影响，应该靠近代码而不是在另一个CMS中。 大多数程序员不是孤立地工作 – 我们为公司工作，作为一个团队的一部分。

考虑到这一点，在Subversion和git之间比较在客户端工具和培训中的易用性。 我看不到任何分布式修订控制系统将更容易使用或向非程序员解释的情况。 我喜欢被certificate是错误的，因为那样我就能够评估git，并且真正希望被那些不是程序员的需要版本控制的人所接受。

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

免责声明：我早在（v0.29左右）就对Subversion感兴趣，所以显然我有偏见，但自那时以来，我曾经工作过的公司都从我的热情中受益，因为我鼓励并支持它的使用。 我怀疑这是大多数软件公司的情况。 有这么多的程序员跳上git的潮stream，我不知道有多less公司会错过在源代码之外使用版本控制的好处？ 即使您为不同的团队设置不同的系统，也会错过一些好处，例如（统一）问题跟踪集成，同时增加维护，硬件和培训要求。

Answer 10

Subversion仍然是一个更为使用的版本控制系统，这意味着它有更好的工具支持。 几乎所有的IDE都会find成熟的SVN插件，并且有很好的资源pipe理器扩展（比如TurtoiseSVN）。 除此之外，我不得不同意Michael的观点：Git并不比Subversion好或者差，这是不同的。

Answer 11

SubVersion令我感到厌烦的是，它将自己的文件夹放在项目的每个目录中，而git只把它放在根目录下。 这不是什么大不了的事情，但是像这样的小事加起来。

当然，SubVersion有乌龟，这通常是非常好的。

Answer 12

David Richards WANdisco博客Subversion / GIT

GIT的出现带来了一系列DVCS原教旨主义者 – 'Gitterons' – 认为GIT以外的任何东西都是废话。 Gitterons似乎认为软件工程发生在他们自己的岛屿上，并且经常忘记大多数组织并不专门聘用高级软件工程师。 没关系，但并不是市场其他人认为的，我很高兴certificate这一点：GIT在上一次看来只占市场的不到3％，而Subversion在500万用户的地区，大约一半整体市场。

我们看到的问题是，Gitterons在Subversion发射（廉价）镜头。 推文如“Subversion是如此[缓慢/蹩脚/限制性/不闻味道好/看着我在一个有趣的方式]现在我有GIT和[一切工作在我的生活/我的妻子怀孕/我有一个女朋友后30年的尝试/我赢了六次在二十一点桌运行]。 你得到的照片。

Answer 13

Git也使分支和合并非常容易。 Subversion 1.5刚刚添加合并跟踪，但是Git还是比较好的。 与Git分支是非常快速和便宜的。 这使得为​​每个新function创build一个更可行的分支。 哦，Git仓库与Subversion相比，存储空间非常高效。

Answer 14

这一切都是为了做一些事情所需的易用性/步骤。

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

如果只有两个人，我会说git也比较容易，因为你可以互相推拉。

一旦你超越了这一点，我会去颠覆，因为那时你需要build立一个“专用”的服务器或位置。

你可以像使用SVN一样使用git来做到这一点，但是git的好处被需要做额外的步骤与中央服务器同步的需要所抵消。 在SVN中你只是提交。 在混帐你必须提交，然后混帐推。 额外的步骤很烦人，因为你最终会这么做。

SVN也有更好的GUI工具的好处，但git生态系统似乎正在赶上，所以我不会为此长期担心。

Answer 15

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

Answer 16

一般来说，Git和DVCS对开发者来说是非常好的，因为每个人都有自己的分支。 如果你需要别人的改变，她必须承诺自己的本地回购，然后她必须把这个改变集合给你，否则你必须把它从她身上拉下来。

我自己的推理也让我认为，如果您执行集中式发布等操作，DVCS会使QA和发布pipe理变得更加困难。 有人必须负责从其他人的存储库进行推送/解压，解决在最初提交时间之前解决的任何冲突，然后进行构build，然后让所有其他开发人员重新同步其回购。

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

Answer 17

我喜欢Git，因为它实际上可以帮助通信开发者开发一个大中型团队。 作为一个分布式版本控制系统，通过其推/拉系统，它可以帮助开发人员创build一个源代码生态系统，帮助pipe理大量开发人员在一个项目上工作。

例如，假设您信任5个开发人员，并只从其存储库中提取代码。 每个开发人员都有自己的信任networking，从他们拉代码的地方。 因此，开发是基于开发人员共享代码责任的开发人员的信任结构。

当然，在这里的其他答案中还有其他的好处。

Answer 18

有几个答案已经提到了这些，但我想明确地指出两点：

1）能够做select性的提交（例如， git add --patch ）。 如果您的工作目录包含多个不属于同一逻辑更改的更改，Git使提交变得非常简单，只包含一部分更改。 有了Subversion，这很难。

2）在不公开变更的情况下进行承诺的能力。 在Subversion中，任何提交都是立即公开的，因此是不可撤销的。 这极大地限制了开发人员“早期提交，经常执行”的能力。

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

Answer 19

我认为Subversion是好的..直到你开始合并..或做任何复杂的事情或做任何事Subversion认为是复杂的（就像做查询找出哪些分支与特定文件混淆， 实际上来自哪里，检测复制和粘贴等等）…

我不同意这个获胜的答案，说GIT的主要好处是离线工作 – 这当然是有用的，但它更像是一个额外的用例。 SVK也可以离线工作，对我来说，还有什么问题可以投入我的学习时间）。

只是它非常强大和快速，而且在习惯了这些概念之后 – 非常有用（是的，在这个意义上说：用户友好）。

有关合并故事的更多详细信息，请参阅： 使用git-svn（或类似的）*只是*来帮助svn合并？

Answer 20

由于事实上它不需要经常与中央服务器进行通信，所以几乎每个命令都在不到一秒的时间内运行（显然，git push / pull / fetch的速度较慢，仅仅是因为它们需要初始化SSH连接）。 分支要容易得多（一个简单的分支命令，一个简单的命令合并）

Answer 21

我非常喜欢能够在Git中pipe理我的源代码的本地分支，而不会淹没中央资源库的水。 在许多情况下，我会从Subversion服务器检出代码，并运行一个本地Git存储库，以便能够执行此操作。 初始化一个Git仓库不会在每个地方都有一堆讨厌的.svn文件夹污染文件系统。

就Windows工具支持而言，TortoiseGit非常好地处理基础知识，但是我仍然更喜欢命令行，除非我想查看日志。 我很喜欢Tortoise {Git | SVN}在读取提交日志时的帮助。

Answer 22

这是一个错误的问题。 把注意力集中在git的瑕疵上是非常容易的，并且为什么颠覆表面上更好，至less对于一些用例来说是一个争论。 git最初被devise为一个低级版本控制构造集，并且具有巴洛克式的面向Linux开发者的界面，这使得圣战更容易获得牵引力和合法性。 Git的支持者鼓起了数以百万计的工作stream优势，svn家伙宣称是不必要的。 不久之后，整个辩论被形成为集中式和分布式，这符合企业svn工具团体的利益。 这些公司通常就颠覆在企业中的优势提出最令人信服的文章，这取决于git的不安全感和svn企业为其产品的长期成功做好准备。

但是这里有个问题： Subversion是一个架构的死胡同 。

而你可以很轻松地使用git和build立一个集中式的颠覆replace，尽pipe周围的时间长了两倍多，svn从来没有能够在任何地方进行基本的合并跟踪工作以及在git中工作。 其中一个基本原因是devise决定使分支与目录相同。 我不知道为什么他们原来这样做，这当然使部分结账非常简单。 不幸的是，这也使得无法正确地追踪历史。 现在，显然你应该使用Subversion版本库布局约定将分支从常规目录中分离出来，而svn使用一些启发式的方法来使日常用例成为可能。 但是，这一切只是在一个非常糟糕和有限的低层devise决策上进行的。 能够做一个版本库差异（而不是目录明智的差异）是版本控制系统的基本和关键function，并大大简化了内部，使它有可能build立在其上的更聪明和有用的function。 你可以看到已经投入到扩展颠覆的努力，但是就像合并解决这样的基本操作而言，与现代VCS的当前作物相比还有多远。

对于那些仍然认为Subversion在可预见的将来已经足够好的人来说，这里是我的心声和不可知论的build议：

Subversion永远赶不上从RCS和CVS的错误中学到的VCS的新品种; 除非他们从头开始重新build立储存库模型，否则这是一种技术上的不可能的事情，但是这样做不是真的吗？ 不pipe你觉得你现在的VCS的能力如何，你的无知无法保护你免受Subversion的陷阱，其中许多是其他系统中不可能或容易解决的情况。

一个解决scheme的技术劣势与svn一样明显是非常罕见的，当然，我绝对不会对win-vs-linux或者emacs-vs-vi这么说，但是在这种情况下，清除和源代码控制是开发者库中的一个基本工具，我觉得必须明确地说明。 不pipe为什么使用svn出于组织原因，我恳求所有的svn用户不要让他们的逻辑思维构build一个错误的信念，即更多的现代VCS只对大型的开源项目有用。 不pipe开发工作的性质如何，如果你是一名程序员，如果你学习如何使用devise良好的VCS，无论是Git，Mercurial，Darcs还是其他的，都将成为一名更有效的程序员。

Answer 23

Subversion非常易于使用。 在过去的几年中，我从来没有发现过一个问题，或者有些东西不能按预期工作。 还有很多优秀的graphics用户界面工具，SVN集成的支持也很大。

借助Git，您可以获得更灵活的VCS。 你可以像SVN一样用远程仓库来提交所有的修改。 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 😉

If you work mostly offline with your local repository you have no backup if something is lost on your local machine. With SVN you are mostly working with a remote repository which is also the same time your backup on another server… Git can work in the same way but this was not the main goal of Linus to have something like SVN2. It was designed for the Linux kernel developers and the needs of a distributed version control system.

Is Git better then SVN? Developers which needs only some version history and a backup mechanism have a good and easy life with SVN. Developers working often with branches, testing more versions at the same time or working mostly offline can benefit from the features of Git. There are some very useful features like stashing not found with SVN which can make the life easier. But on the other side not all people will need all features. So I cannot see the dead of SVN.

Git needs some better documentation and the error reporting must be more helpful. Also the existing useful GUIs are only rarely. This time I have only found 1 GUI for Linux with support of most Git features (git-cola). Eclipse integration is working but its not official released and there is no official update site (only some external update site with periodical builds from the trunk http://www.jgit.org/updates ) So the most preferred way to use Git this days is the command line.

Answer 24

Eric Sink from SourceGear wrote series of articles on differences between distributed and nondistributed version controls systems. He compares pros and cons of most popular version control systems. Very interesting reading.
Articles can be found on his blog, http://www.ericsink.com :

• Read the Diffs

• Git is the C of Version Control Tools

• On Git's lack of respect for immutability and the Best Practices for a DVCS

• DVCS and DAGs, Part 1

• DVCS and DAGs, Part 2

• DVCS and Bug Tracking

• Merge History, DAGs and Darcs

• Why is Git so Fast?

• Mercurial, Subversion, and Wesley Snipes

Answer 25

For people looking for a good Git GUI, Syntevo SmartGit might be a good solution. Its proprietary, but free for non-commercial use, runs on Windows/Mac/Linux and even supports SVN using some kind of git-svn bridge, I think.

Answer 26

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

I think it's fairly safe to say that amongst developers, the SVN Vs. Git argument has been raging for some time now, with everyone having their own view on which is better. This was even brought up in the of the questions during our Webinar on Subversion in 2010 and Beyond.

Hyrum Wright, our Director of Open Source and the President for the Subversion Corporation talks about the differences between Subversion and Git, along with other Distributed Version Control Systems (DVCS).

He also talks about the upcoming changes in Subversion, such as Working Copy Next Generation (WC-NG), which he believes will cause a number of Git users to convert back to Subversion.

Have a watch of his video and let us know what you think by either commenting on this blog, or by posting in our forums. Registration is simple and will only take a moment!

Answer 27

Git in Windows is quite well supported now.

Check out GitExtensions = http://code.google.com/p/gitextensions/

and the manual for a better Windows Git experience.

Answer 28

I have been dwelling in Git land lately, and I like it for personal projects, but I wouldn't be able to switch work projects to it yet from Subversion given the change in thinking of required from staff, without no pressing benefits. Moreover the biggest project we run in-house is extremely dependent on svn:externals which, from what I've seen so far, does not work so nicely and seamlessly in Git.

Answer 29

First, concurrent version control seems like an easy problem to solve. It's not at all. 无论如何…

SVN is quite non-intuitive. Git is even worse. [sarcastic-speculation] This might be because developers, that like hard problems like concurrent version control, don't have much interest in making a good UI. [/sarcastic-speculation]

SVN supporters think they don't need a distributed version-control system. I thought that too. But now that we use Git exclusively, I'm a believer. Now version control works for me AND the team/project instead of just working for the project. When I need a branch, I branch. Sometimes it's a branch that has a corresponding branch on the server, and sometimes it does not. Not to mention all the other advantages that I'll have to go study up on (thanks in part to the arcane and absurd lack of UI that is a modern version control system).

Answer 30

Why I think Subversion is better than Git (at least for the projects I work on), mainly due to its usability, and simpler workflow:

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