我正在开始一个新的分布式项目。我应该使用SVN还是Git，为什么？

解决方案

我会选择SVN，因为它的传播范围更广，知名度更高。

我猜想，对于Linux用户，Git会更好。

Windows目前还不支持Git。它已针对Posix系统进行了优化。但是，运行Cygwin或者MinGW可使我们成功运行Git。

如今，我更喜欢Git而不是SVN，但是如果我们来自CVS和SVN领域，则需要花费一些时间才能超过阈值。

绝对是svn，因为Windows至少是git世界中的第二等公民(有关更多详细信息，请参见http://en.wikipedia.org/wiki/Git_(software)#Portability)。

更新：很抱歉断开的链接，但是我已经放弃了让SO与包含括号的URI一起工作的尝试。 [现在已修复链接。 -ed]

我可能会选择Git，因为我觉得它比SVN更强大。有便宜的代码托管服务可用，对我来说非常有用，我们无需进行备份或者任何维护工作GitHub是最明显的选择。

就是说，我对Visual Studio和其他SCM系统的集成一无所知。我想象与SVN的集成要好得多。

要点是，Git是分布式VCS，Subversion是集中式VCS。分布式VCS有点难以理解，但是有很多优点。如果我们不需要此优点，则Subversion可能是更好的选择。

另一个问题是工具支持。我们计划使用哪些工具更好地支持哪个VCS？

编辑：三年前，我以这种方式回答：

And Git works on Windows at the moment only via Cygwin or MSYS.
  Subversion supported Windows from the beginning. As the git-solutions
  for windows may work for you, there may be problems, as the most
  developers of Git work with Linux and didn't have portability in the
  mind from the beginning. At the moment I would prefer Subversion for
  development under Windows. In a few years this may be irrelevant.

现在，世界已经发生了一些变化。 Git现在在Windows上具有良好的实现。尽管我没有在Windows上进行彻底的测试(因为我不再使用该系统)，但我很有信心，所有主要的VCS(SVN，Git，Mercurial，Bazaar)现在都具有正确的Windows实现。 SVN的这一优势消失了。其他要点(集中式与分布式以及对工具支持的检查)保持有效。

我可以扩展一下这个问题，并询问Git在MacOS上是否运行良好？

回复评论：感谢消息，我一直期待尝试。我将在Mac上在家安装它。

SVN是一个回购协议，有很多客户。 Git是一个包含许多客户端存储库的存储库，每个客户端存储库都有一个用户。它的分散性使人们可以在本地跟踪自己的编辑，而不必将内容推送到外部服务器。

SVN被设计为更加集中，其中Git基于每个拥有自己Git存储库的用户，而这些存储库将更改推回中央。因此，Git为个人提供了更好的本地版本控制。

同时，我们可以在TortoiseGit和GitExtensions之间进行选择(如果我们在GitHub上托管"中央" git存储库，则在Windows上拥有自己的客户端GitHub)。

如果我们正打算退出SVN，则可能需要对Bazaar进行一些评估。它是具有此分布式元素的下一代版本控制系统之一。它不像git那样依赖POSIX，因此存在本机Windows版本，并且它具有一些强大的开源品牌作为后盾。

但是我们可能甚至不需要这些功能。了解分布式VCS的功能，优点和缺点。如果我们需要的不仅仅是SVN产品，请考虑其中之一。如果我们不这样做，则可能要坚持使用SVN(当前)的高级桌面集成。

我将建立一个Subversion存储库。通过这种方式，各个开发人员可以选择使用Subversion客户端还是Git客户端(带有git-svn)。使用git-svn并不能为我们提供完整的Git解决方案的所有好处，但是它确实为单个开发人员提供了对其自己的工作流程的大量控制。

我相信Git在Windows上能够像在Unix和Mac OS X上一样好运行的时间相对较短(根据要求)。

Subversion具有适用于Windows的出色工具，例如用于Explorer Explorer集成的TortoiseSVN和用于Visual Studio集成的AnkhSVN。

正如其他人指出的那样，在Windows下SVN似乎是一个不错的选择。

如果某些开发人员想尝试GIT，则它可能总是使用GIT-SVN，其中在GIT存储库中重新创建了SVN存储库。然后，他应该能够在本地使用GIT，然后使用SVN将其更改发布到主存储库。

我们尝试过Bzr吗？

非常好，因为他们不喜欢市场上的其他东西，所以(使Ubuntu的人)产生了怀疑的态度。

我从来没有理解过" git在Windows上效果不好"的概念。我专门在Windows下开发，而git从来没有任何问题。

我绝对会推荐git而不是subversion；它的用途更加广泛，并允许以"颠覆"从未有过的方式进行"离线开发"。它在几乎可以想象到的每个平台上都可用，并且具有比我们可能会使用的更多的功能。

我们必须使用DVCS，这就像源管理中的一次飞跃。我个人使用Monotone，它加快了开发时间，没有尽头。我们将其用于Windows，Linux和Mac，并且非常稳定。我什至让buildbot在每个平台上每晚进行项目的构建。

分发时，DVCS通常意味着我们将创建一个中央服务器，仅用于人们来回推送更改。

并不是真正回答问题，但是如果我们希望获得分布式修订版本控制的好处，听起来像我们一样，并且我们正在使用Windows，我想最好使用Mercurial，而不是Git，因为Mercurial具有更好的Windows支持。 Mercurial确实也有Mac端口。

YouTube上有一个有趣的视频。来自Linus Torwalds本人：Goolge技术讲座：git上的Linus Torvalds

如果团队已经熟悉cvs或者svn等版本和源代码控制软件，那么对于一个简单的小型项目(例如我们声称的那样)，我建议我们使用SVN。我对svn真的很满意，但是对于我目前在django上进行的电子商务项目，我决定使用git(我在svn模式下使用git，也就是说，使用了我推送并拉出的集中存储库以便与至少一位其他开发人员合作)。另一个开发人员对SVN感到满意，尽管其他人的经验可能有所不同，但对于这个小项目，我们两个人在拥抱git时都经历了非常糟糕的时光。 (如果有关系的话，我们都是Linux核心用户。)

当然，里程可能会有所不同。

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

请阅读在Google Code项目上使用Git进行开发

Although Google Code natively speaks
  Subversion, you can easily use Git
  during development. Searching for "git
  svn" suggests this practice is
  widespread, and we too encourage you
  to experiment with it.

在Svn存储库上使用Git给我带来了好处：

• 我可以在多台计算机上进行分布式工作，并在它们之间进行提交和拉取
• 我有一个中央的backup / publicsvn存储库，供其他人签出
• 他们可以自由使用Git

SVN的2个关键优势很少被提及：

• 大文件支持。除了代码之外，我还使用SVN来管理我的主目录。 SVN是唯一一个不会阻塞我的TrueCrypt文件的VCS(无论是否分布式)(如果还有另一个VCS有效处理500MB以上的文件，请纠正我)。这是因为流比较比较(这是非常重要的一点)。 Rsync是不可接受的，因为它不是2路的。
• 部分存储库(子目录)检出/检入。 Mercurial和bzr不支持此功能，而git的支持很有限。这在团队环境中是不好的，但是如果我想从主目录在另一台计算机上签出某项东西，那将是无价的。

只是我的经验。

这是我对一些重复问题做出的回答的副本，此后就删除了有关Git对SVN的问题(2009年9月)。

更好的？除了通常的链接WhyGitIsBetterThanX之外，它们是不同的：

一个是基于廉价副本的分支机构和标签的中央VCS
另一个(Git)是基于修订图的分布式VCS。
另请参见VCS的核心概念。

第一部分产生了一些误导性的评论，声称这两个程序(SVN和Git)的基本目的是相同的，但是实现起来却大不相同。
为了阐明SVN和Git之间的根本区别，让我改写一下：

• SVN是版本控制的第三个实现：RCS，然后是CVS，最后是SVN，管理版本数据的目录。 SVN提供了VCS功能(标记和合并)，但是它的标签只是目录副本(像分支一样，除了不"应该"接触标签目录中的任何内容)，而且它的合并仍然很复杂，目前基于meta -添加数据以记住已经合并的内容。
• Git是一种文件内容管理(一种用于合并文件的工具)，已基于提交的DAG(定向非循环图)发展成一个真正的版本控制系统，其中分支是数据历史记录的一部分(而不是数据本身) )，而标记是真正的元数据。

说它们没有"根本上的"不同是因为我们可以实现相同的目标，解决相同的问题，这是……在许多层面上都是错误的。

• 如果我们有许多复杂的合并，则使用SVN进行合并会更长，并且更容易出错。如果必须创建许多分支，则需要管理它们并合并它们，与SVN相比，使用Git再次容易得多，尤其是在涉及大量文件的情况下(速度变得很重要)
• 如果我们要进行的工作有部分合并，则将利用Git暂存区(索引)来仅提交所需的内容，将其余的内容存储起来，然后在另一个分支上移动。
• 如果我们需要离线开发...与Git一起使用，我们总是可以"在线"使用自己的本地存储库，无论我们要遵循其他存储库的工作流程如何。

仍然对该旧(已删除)答案的评论坚持：

VonC: You are confusing fundamental difference in implementation (the differences are very fundamental, we both clearly agree on this) with difference in purpose.

  They are both tools used for the same purpose: this is why many teams who've formerly used SVN have quite successfully been able to dump it in favor of Git.

  If they didn't solve the same problem, this substitutability wouldn't exist.

，我回答了：

"可替代性" ...一个有趣的术语(在计算机编程中使用)。
当然，Git几乎不是SVN的子类型。

我们可能同时获得了相同的技术功能(标签，分支，合并)，但是Git并没有妨碍我们，让我们可以专注于文件的内容，而无需考虑工具本身。

我们肯定不能(总是)仅用Git替换SVN，而无需更改该程序的任何期望属性(正确性，执行的任务等)(这是对上述可替换性定义的引用)：

• 一个是扩展的修订工具，另一个是真正的版本控制系统。
• 一个适合中小型整体项目，具有简单的合并工作流程和(不是太多)并行版本。 SVN足以满足此目的，我们可能不需要所有的Git功能。
• 另一个允许基于多个组件的中型到大型项目(每个组件一个回购)，在复杂的合并工作流中的多个分支之间要合并的文件数量很多，分支中的并行版本，改造合并等等。我们可以使用SVN来做到这一点，但是使用Git则要好得多。 SVN根本无法使用任何合并工作流来管理任何规模的任何项目。 git可以。

同样，它们的本质从根本上是不同的(这将导致不同的实现，但这不是重点)。
一个人将修订控制视为目录和文件，另一个人仅看到文件的内容(以至于空目录甚至都不会在Git中注册！)。

通用最终目标可能是相同的，但是我们不能以相同的方式使用它们，也不能解决相同类别的问题(范围或者复杂性)。

我使用SVN已有很长时间了，但是每当使用Git时，我都觉得Git功能强大，轻巧，虽然涉及到一些学习过程，但比SVN更好。

我注意到的是，每个SVN项目随着其增长，除非导出，否则会变成一个很大的项目。此外，GIT项目(以及Git数据)的大小非常轻巧。

在SVN中，我与从新手到专家的开发人员打交道，并且如果新手和中间人从另一个SVN项目复制一个文件夹以重新使用它，则新手和中间人似乎会引入文件冲突。而我认为在Git中，我们只需复制文件夹即可使用，因为Git不会在其所有子文件夹中引入.git文件夹(就像SVN一样)。

经过很长时间与SVN的交易之后，我终于考虑将我和我的开发人员转移到Git，因为它很容易协作和合并工作，并且一个很大的优点是可以尽可能多地执行本地副本的更改。期望，然后最终一次推送到服务器上的分支，这与SVN不同(在SVN中，我们必须不时在服务器上的存储库中提交更改)。

任何可以帮助我决定是否真的应该与Git一起使用的人吗？

在进行了更多研究之后，并查看了以下链接：https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(以下摘录)：

• 它的速度非常快。我使用过的其他SCM都无法跟上它，并且我使用了很多，包括Subversion，Perforce，darcs，BitKeeper，ClearCase和CVS。
• 它是完全分布式的。存储库所有者无法决定我的工作方式。我可以在笔记本电脑上断开连接时创建分支并提交更改，然后将其与任意数量的其他存储库同步。
• 同步可以在许多媒体上发生。 SSH通道，通过WebDAV通过HTTP，通过FTP或者通过发送电子邮件(包含将由消息的接收者应用的补丁程序)通过HTTP。中央存储库不是必需的，但可以使用。
• 分支甚至比Subversion中的便宜。创建分支就像将41个字节的文件写入磁盘一样简单。删除分支就像删除该文件一样简单。
• 与Subversion不同，分支具有完整的历史记录。无需执行奇怪的副本并遍历副本。使用Subversion时，我总是发现查看创建分支之前发生的分支上文件的历史记录很尴尬。来自#git：矛：我不了解页面中有关SVN的一件事。我在SVN上创建了一个分支，浏览历史记录显示整个历史记录在该分支中
• 在Git中，分支合并更简单，更自动化。在Subversion中，我们需要记住我们合并的最新修订版本，以便可以生成正确的合并命令。 Git会自动执行此操作，并且始终会正确执行。这意味着将两个分支合并在一起时犯错的可能性较小。
• 分支合并记录为存储库正确历史记录的一部分。如果我将两个分支合并在一起，或者将一个分支合并回到它来自的主干中，那么该合并操作将记录为重新发布历史的一部分，并由我以及何时执行。很难确定是谁在日志中执行了合并。
• 创建存储库是一项简单的操作：mkdir foo; cd foo; git init就是这样。这意味着我最近为所有内容创建了一个Git存储库。我倾向于在每个班级使用一个存储库。这些存储库中大多数都在磁盘中，不到1 MB，因为它们仅存储讲义，家庭作业和我的LaTeX答案。
• 存储库的内部文件格式非常简单。这意味着修复非常容易，但是更好，因为修复是如此简单，很难被损坏。我认为没有人曾经有过Git信息库遭到破坏。我已经看到带有fsfs的Subversion本身已损坏。而且我已经看到Berkley DB自身损坏太多次了，无法将我的代码信任到Subversion的bdb后端。
• 尽管Git的文件格式非常简单，但它非常擅长压缩数据。 Mozilla专案的CVS储存库约为3 GB； Subversion的fsfs格式约为12 GB。在Git中约为300 MB。

阅读完所有这些内容后，我相信Git是必经之路(尽管存在一些学习上的困难)。我也在Windows平台上使用过Git和SVN。

阅读以上内容后，我想听听其他人怎么说？