我应该使用SVN还是Git？
我正在开始一个新的分布式项目。 我应该使用SVN还是Git？为什么？
SVN是一个回购和许多客户。 Git是一个有很多客户端回购的回购，每个都有一个用户。 它是分散的，人们可以在本地跟踪自己的编辑，而无需将内容推送到外部服务器。
SVN被devise得更加中心，Git基于每个用户都拥有自己的Git仓库，而这些仓库将更改推回到中央仓库。 出于这个原因，Git给个人更好的本地版本控制。
同时你可以selectTortoiseGit ， GitExtensions （如果你在github上托pipe你的“中央”git-repository，他们自己的客户端 – 用于Windows的GitHub ）。
如果你正在寻找离开SVN，你可能要评估一下Bazaar 。 这是拥有这种分布式元素的下一代版本控制系统之一。 它不像POSIX那样依赖于POSIX，所以有了原生的Windows版本 ，并且拥有一些支持它的强大的开源品牌。
但是，你甚至可能不需要这些function。 看看分布式VCS的特性，优点和缺点 。 如果您需要比SVN优惠多，请考虑一个。 如果你不这样做，你可能想要坚持SVN的（当前）优越的桌面集成。
我从来没有理解过“在Windows上不好”的概念。 我完全在Windows下开发，我从来没有与Git的任何问题。
我肯定会推荐git over subversion; 它只是非常多才多艺，并以颠覆性的方式实现“离线开发”。 它几乎可以在任何可以想象的平台上使用，并具有比您可能使用的function更多的function。
这里是一个我从一些重复的问题的答案副本， 因为从 Git与SVN（2009年9月） 删除 。
更好？ 除了通常的链接WhyGitIsBetterThanX ，它们是不同的：
一个是基于廉价的分支和标签的VCS的中央VCS（Git）是一个基于修订图的分布式VCS。 另请参见VCS的核心概念 。
第一部分产生了一些错误的评论，假设这两个程序（SVN和Git）的基本目的是相同的，但是它们的实现方式有很大不同。
为了澄清SVN和Git之间的根本区别 ，让我换个口吻：
-
SVN是版本控制的第三个实现： RCS，然后是CVS，最后是SVNpipe理版本化数据的目录。 SVN提供了VCSfunction（标签和合并），但是它的标签只是一个目录副本（就像一个分支，除非你不能“接触”标签目录中的任何东西），它的合并仍然很复杂，目前基于元添加数据以记住已经合并的内容。
-
Git是一个文件内容pipe理 （合并文件的工具）， 演变成一个真正的版本控制系统 ，基于提交的DAG（有向无环图 ），其中分支是数据历史的一部分（而不是数据本身），标签是一个真正的元数据。
说他们不是“根本上”不同，因为你可以做到同样的事情，解决同样的问题，在这么多的层面上……是纯粹的错误。
- 如果你有很多复杂的合并，那么用SVN做它们会更长，更容易出错。 如果你不得不创build许多分支，你将需要pipe理它们并合并它们，而使用Git要比使用SVN更容易，特别是在涉及大量文件的情况下（速度变得重要）
- 如果你正在进行一个工作的部分合并，你将利用Git临时区域（索引）来只提交你需要的东西，把剩下的东西存储起来，然后在另一个分支上继续。
- 如果你需要离线开发…和Git一样，你总是“在线”，用你自己的本地仓库，无论你想要跟其他仓库工作stream程。
尽pipe如此，老（删除）答案的评论坚持：
VonC：你在实施上的根本区别（差异是非常基本的，我们都明确同意这一点），目的不同。
他们都是用于相同目的的工具：这就是为什么许多以前使用SVN的团队已经相当成功地将其倾倒到Git上。
如果他们不解决同样的问题，这种替代性将不存在。
我回答说：
“可替代性”…有趣的术语（ 用于计算机编程 ）。
当然，Git几乎不是SVN的子types。
你可以用这两种技术实现相同的技术特性（标签，分支和合并），但是Git不会妨碍你的工作，并且让你专注于文件的内容 ，而不用考虑工具本身。
你当然不能（总是）用GitreplaceSVN而不改变该程序的任何期望属性（正确性，任务执行…）（这是对前述可replace性定义的引用）：
- 一个是扩展版本工具，另一个是真正的版本控制系统。
- 一个适用于简单的合并工作stream程和（不太多）并行版本的中小型单一项目。 SVN就足够了，你可能不需要所有的Git特性。
- 另一个允许基于多个组件（ 每个组件一个回购 ）的大中型项目，在复杂合并工作stream中的多个分支之间合并大量文件，在分支中并行版本，改进合并等等。 你可以用SVN来做，但是用Git你会更好。
SVN根本无法用任何合并工作streampipe理任何大小的项目。 Git可以。
再一次， 它们的性质是根本不同的 （这导致了不同的实现，但这不是重点）。
一个将修订控制看作是目录和文件，另一个只能看到文件的内容（甚至空目录甚至不会在Git中注册！）。
一般的最终目标可能是一样的，但不能以相同的方式使用它们，也不能解决同一类问题（范围或复杂性）。
很less引用SVN的两个关键优势：
-
大文件支持。 除了代码，我使用SVN来pipe理我的主目录。 SVN是唯一不会扼杀我的TrueCrypt文件的VCS（请分辨我是否有另一个可以有效处理500MB +文件的VCS）。 这是因为比较比较stream传输（这是一个非常重要的点）。 Rsync是不可接受的，因为它不是双向的。
-
部分存储库（subdir）结帐/签入。 Mercurial和bzr不支持这个，而git的支持是有限的。 这在团队环境中是不好的，但是如果我想从家里的另一台计算机上检查某些东西，这是非常宝贵的。
只是我的经验。
在做了更多的研究之后，回顾一下这个链接： https ： //git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html
（以下摘录）：
- 这是非常快的。 没有其他的SCM能够跟上，我用了很多，包括Subversion，Perforce，darcs，BitKeeper，ClearCase和CVS。
- 它完全分布。 存储库所有者不能规定我的工作方式。 我可以在我的笔记本电脑上断开连接时创build分支并提交更改，然后将其与任意数量的其他存储库进行同步。
- 同步可以发生在很多媒体上。 SSH通道，通过HTTP通过WebDAV，通过FTP，或通过发送电子邮件持有由邮件的接收者应用的补丁。 中央存储库不是必需的，但可以使用。
- 分支甚至比在Subversion中便宜。 创build一个分支就像写一个41字节的文件到磁盘一样简单。 删除分支就像删除那个文件一样简单。
- 与Subversion分支不同，它们带有完整的历史。 而不必执行一个奇怪的副本，并通过副本。 在使用Subversion的时候，我总是发现在分支被创build之前发生在分支上的文件的历史。 从#git：spearce：我不明白关于页面中的SVN的一件事。 我做了一个分支我SVN和浏览历史显示整个历史在分支文件
- 分支合并在Git中更简单，更自动化。 在Subversion中，你需要记住你最后一次修改版本是什么，所以你可以生成正确的合并命令。 Git自动执行此操作，并始终做对了。 这意味着在将两个分支合并在一起时，出现错误的可能性较小。
- 分支合并被logging为存储库适当历史的一部分。 如果我将两个分支合并在一起，或者如果我将一个分支合并到它的后备箱中，合并操作将被logging为由我执行的以及何时执行的转储历史的一部分。 当日志正确的时候，谁来执行合并是很难的。
- 创build一个仓库是一个简单的操作：mkdir foo; cd foo; git init就是这样。 这意味着我为这些日子的一切创build了一个Git仓库。 我倾向于每个类使用一个存储库。 这些存储库大部分都在1MB以下，因为它们只存储讲义，家庭作业和我的LaTeX答案。
- 存储库的内部文件格式非常简单。 这意味着修复是非常容易的，但更好，因为它非常简单，很难被破坏。 我不认为有人曾经有一个Git仓库被损坏。 我已经看到与FSF的Subversion本身腐败。 而且我已经看到Berkley DB本身腐败了很多次，以至于把我的代码信任到Subversion的bdb后端。
- 尽pipe它是一个非常简单的格式，但是Git的文件格式在压缩数据方面非常出色。 Mozilla项目的CVS存储库大约3 GB; Subversion的fsfs格式大概是12GB。 在Git大约300 MB。
看完所有这些之后，我确信Git是最好的select（尽pipe存在一点点的学习曲线）。 我也在Windows平台上使用过Git和SVN。
在阅读完上面的内容之后，我很想听听其他人不得不说的话吗？
我会build立一个Subversion版本库。 通过这样做，个人开发人员可以select是否使用Subversion客户端或Git客户端（使用git-svn ）。 使用git-svn并不能给你一个完整的Git解决scheme的所有好处，但它确实可以让个人开发者对他们自己的工作stream程有很大的控制。
我相信Git在Windows和Unix和Mac OS X上运行的时间相当短（因为你问过）。
Subversion具有优秀的Windows工具，如用于Explorer集成的TortoiseSVN和用于Visual Studio集成的AnkhSVN。
有趣的是：我在Subversion Repos中托pipe项目，但通过Git Clone命令访问它们。
请阅读Google代码项目中的使用Git开发
虽然谷歌代码本身就说Subversion，但是在开发过程中可以很容易的使用Git。 search“git svn”表明这种做法是普遍的，我们也鼓励你去试验它。
在Svn Repository上使用Git给我带来好处：
- 我可以在几台机器上工作，承诺和从他们拉
- 我有一个中央
backup/publicsvn库供他人检查 - 而且他们可以自由地使用Git
绝对是svn ，因为Windows在git的世界里是最好的二等公民（详见http://en.wikipedia.org/wiki/Git_(software)#Portability ）。
更新：对于断开的链接抱歉，但我已经放弃尝试使用包含圆括号的URI工作。 [现在链接已修复。 -ed]
不是真的回答你的问题，但如果你想分布式修订控制的好处 – 听起来像你这样做 – 而你使用的Windows我认为你最好使用Mercurial而不是Git Mercurial有更好的Windows支持。 Mercurial也有一个Mac端口。
如果你的团队已经熟悉CVS或SVN等版本和源代码控制软件，那么对于一个简单和小型的项目（比如你自称的），我build议你坚持使用SVN。 我对svn感到很舒服，但是对于当前在django上做的电子商务项目，我决定在git上工作（我在svn模式下使用git，也就是用一个集中的repo，从而与至less一个其他开发者合作）。 另外一个开发人员对SVN感觉很舒服，而其他人的经验可能不一样，我们两个都在为这个小项目抱着一个非常糟糕的时间。 （我们都是硬核Linux用户，如果它很重要。）
当然，你的里程可能会有所不同。
我会selectSVN，因为它更广泛和更广为人知。
我猜，Git对Linux用户会更好。
主要的一点是，Git是一个分布式的VCS，Subversion是一个集中式的。 分布式VCS有点难以理解，但有很多优点。 如果你不需要这个优点，Subversion可能是更好的select。
另一个问题是工具支持。 您计划使用的工具支持哪个VCS？
编辑：三年前我这样回答：
而Git目前只能通过Cygwin或MSYS在Windows上运行。 Subversion从一开始就支持Windows。 由于windows的git解决scheme可能适合你，所以可能会有问题，因为Git的大多数开发人员都在Linux上工作，从一开始就没有可移植性。 目前我宁愿在Windows下开发Subversion。 在几年内，这可能是无关紧要的。
现在世界已经改变了一点点。 Git在windows上有很好的实现。 尽pipe我没有在Windows上进行过testing（因为我不再使用这个系统），但我相当自信，所有主要的VCS（SVN，Git，Mercurial，Bazaar）都有适当的Windows实现。 SVN的这个优势已经消失了。 其他方面（集中式与分布式以及工具支持检查）保持有效。
在Windows下，Git本身不受支持。 它为Posix系统进行了优化。 不过运行Cygwin或者MinGW可以让你运行Git成功。
现在，我更喜欢Git over SVN，但是如果你来自CVS，SVN的话，需要一段时间才能超过门槛。
我可能会selectGit，因为我觉得它比SVN强大得多。 有便宜的代码托pipe服务，这对我来说很好 – 你不必做备份或任何维护工作 – GitHub是最明显的候选人。
也就是说，我不知道有关Visual Studio和不同SCM系统的集成。 我想像与SVN的整合显着更好。
我已经使用SVN了很长一段时间，但是每当我使用Git时，我都觉得Gitfunction强大，重量轻，虽然涉及到一点学习曲线，但是比SVN更好。
我注意到，每个SVN项目，随着它的发展，除非它被导出，否则它将成为一个非常大的项目。 GIT项目（与Git数据一起）的体积非常轻。
在SVN中，我已经把开发人员从新手处理到专家，新手和中间人似乎引入了文件冲突，如果他们从另一个SVN项目复制一个文件夹，以便重新使用它。 而我认为在Git中，你只是复制文件夹，它的工作原理，因为Git不会在其所有子文件夹（如SVN）中引入.git文件夹。
自从很长一段时间以来，与SVN交stream很多，我终于想把我的开发人员和我移到Git上，因为协作和合并工作很容易，而且一个很大的好处就是可以尽可能多地承诺本地副本的变更然后最终推送到服务器上的分支，不像SVN（我们必须不时地在服务器上的仓库中提交更改）。
任何人都可以帮我决定是否应该真正使用Git？
这归结为：
你的发展是线性的吗？ 如果是这样，你应该坚持使用Subversion。
另一方面，如果你的开发不是线性的，这意味着你将需要为不同的改变创build分支，然后将这些改变合并回主开发线（Git已知为主分支），那么Git会做对你更多。
你有没有试过Bzr ？
这是非常好的，非常实用的（制造Ubuntu的人）做到这一点，因为他们不喜欢市场上的其他东西。
我可以扩展这个问题，并问Git是否能在MacOS上正常工作？
回复评论：感谢消息，我一直期待着尝试一下。 我会在我的Mac上安装它。
YouTube上有一个有趣的video。 它来自Linus Torwalds本人： Goolge Tech Talk：git上的Linus Torvalds
正如其他人所指出的，SVN在Windows下似乎是一个不错的select。
如果你的一些开发人员想要尝试GIT，那么可能总是使用GIT-SVN，在GIT仓库中重新创buildSVN库。 然后，他应该能够在GIT本地工作，然后使用SVN将其更改发布到主存储库。
你必须去一个DVCS，这就像源代码pipe理的一个飞跃。 我个人使用Monotone，并加快开发时间。 我们正在使用它的Windows，Linux和Mac，它已经非常稳定。 我甚至有buildbot在每个平台上每晚构build项目。
分布式DVCS通常意味着您将创build一个中央服务器，仅供人们向其中推送更改。
