我应该使用SVN还是Git?

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

277934 次浏览
小开

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

我想Git更适合Linux用户。

小开

Git在Windows下还不受本地支持。它针对Posix系统进行了优化。然而，运行Cygwin或MinGW可以让你成功运行Git。

现在我更喜欢Git而不是SVN，但是如果你来自CVS, SVN的土地，它需要一段时间才能超过阈值。

小开

肯定是svn，因为Windows充其量是git世界中的二等公民(更多细节请参阅http://en.wikipedia.org/wiki/Git_(软件)#可移植性)。

更新:抱歉断开的链接，但我已经放弃尝试让SO与包含括号的uri一起工作。[链接现在固定。——编者)

小开

我可能会选择Git，因为我觉得它比SVN强大得多。有一些便宜的代码托管服务对我来说非常有用——你不需要做备份或任何维护工作——GitHub是最明显的候选者。

也就是说，我对Visual Studio和不同的SCM系统的集成一无所知。我认为与SVN的集成会明显更好。

小开

重点是，Git是分布式VCS, Subversion是集中式VCS。分布式vcs比较难理解，但是有很多优点。如果不需要这些优点，Subversion可能是更好的选择。

另一个问题是工具支持。您计划使用的工具更好地支持哪种VCS ?

三年前我是这样回答的:

Git目前只能通过Cygwin或MSYS在Windows上运行。 Subversion从一开始就支持Windows。作为解决方案 对于Windows可能为你工作，可能会有问题，作为最 Git的开发人员在Linux上工作，没有可移植性 心灵从一开始。目前我更喜欢Subversion 在Windows下开发。几年后，这可能就无关紧要了

现在世界发生了一点变化。Git现在在windows上有一个很好的实现。虽然我没有在windows上进行全面测试(因为我不再使用这个系统)，但我很有信心，所有主要的VCS (SVN、Git、Mercurial、Bazaar)现在都有适当的windows实现。SVN的这一优势已经不复存在。其他要点(集中式vs.分布式以及工具支持的检查)仍然有效。

小开

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

回复评论:谢谢你告诉我这个消息，我一直期待着尝试一下。我会把它安装在家里的Mac电脑上。

小开

SVN是一个repo和许多客户端。Git是一个有很多客户端回购的回购，每个客户端都有一个用户。它是去中心化的，人们可以在本地跟踪自己的编辑，而不必将内容推送到外部服务器。

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

同时，你可以在TortoiseGit， GitExtensions(如果你在github上托管你的“中央”git-repository，他们自己的客户端- GitHub for Windows)之间进行选择。

如果你想要脱离SVN，你可能想要计算一下集市。它是具有这种分布式元素的下一代版本控制系统之一。它不像git那样依赖POSIX，所以有原生的Windows版本，它有一些强大的开源品牌支持。

但您甚至可能还不需要这些特性。看看分布式vcs的特点、优缺点。如果您需要的不仅仅是SVN提供的功能，请考虑使用一个。如果您不喜欢，您可能希望坚持使用SVN(目前)的高级桌面集成。

小开

我会设置一个Subversion存储库。通过这样做，个人开发人员可以选择是使用Subversion客户端还是Git客户端(使用git-svn)。使用git-svn并不能给你所有一个完整的Git解决方案的好处，但它确实让个人开发人员对他们自己的工作流有了很大的控制。

我相信Git在Windows上的表现会在相对较短的时间内达到在Unix和Mac OS X上的效果(既然你问了)。

Subversion为Windows提供了出色的工具，例如用于浏览器集成的TortoiseSVN和用于Visual Studio集成的AnkhSVN。

小开

有人指出，在Windows下，SVN似乎是一个不错的选择。

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

小开

你试过Bzr吗?

这很好，cononical(制作Ubuntu的人)制作它是因为他们不喜欢市场上的其他东西……

小开

我从来没有理解过“git在Windows上不好”这个概念;我只在Windows下开发，git从来没有遇到过任何问题。

我绝对推荐git而不是subversion;它只是更加通用，并且允许“离线开发”，这是subversion永远无法做到的。它可以在几乎所有可以想象到的平台上使用，并且拥有比你可能使用过的更多的功能。

小开

你必须使用DVCS，它就像源代码管理的一个量子飞跃。就我个人而言，我使用单调和它加速的开发时间没有结束。我们在Windows、Linux和Mac上使用它，它非常稳定。我甚至让buildbot在每个平台上进行每晚的项目构建。

分布式DVCS通常意味着您将创建一个中央服务器，仅供人们推送更改。

小开

并没有真正回答你的问题，但如果你想要分布式版本控制的好处-听起来是这样的-并且你正在使用Windows，我认为你最好使用水银而不是Git，因为Mercurial有更好的Windows支持。Mercurial也有Mac移植版本。

小开

YouTube上有一个关于这个的有趣视频。它来自Linus Torwalds自己:google Tech Talk: Linus Torvalds谈git

小开

如果您的团队已经熟悉cvs或svn之类的版本和源代码控制软件，那么对于一个简单而小型的项目(就像您声称的那样)，我建议您坚持使用svn。我对svn非常熟悉，但对于目前我在django上做的电子商务项目，我决定在git上工作(我在svn模式下使用git，也就是说，为了与至少一个其他开发人员合作，我使用了一个集中的repo。)另一个开发人员使用SVN很舒服，尽管其他人的经验可能不同，但我们都在这个小项目中使用git时非常不愉快。(我们都是Linux的铁杆用户，如果这有关系的话。)

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

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

请阅读在谷歌代码项目上使用Git开发

虽然谷歌代码原生说话 Subversion，可以轻松使用Git 在开发过程中。搜索“git” Svn建议这种做法是正确的 广泛传播，我们也鼓励你

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

  1. 我可以工作分布式上几个 机器，承诺和从 和他们
  2. 我有一个中央 backup/public svn储存库供其他人检查
  3. 他们可以自由地使用Git
小开

SVN的2个主要优点很少被提及:

  1. 大文件支持。除了代码之外，我还使用SVN来管理我的主目录。SVN是唯一的VCS(分布式或非分布式)，不会阻塞我的TrueCrypt文件(请纠正我，如果有另一个VCS有效处理500MB以上的文件)。这是因为差异比较是流式的(这是非常重要的一点)。Rsync是不可接受的因为它不是双向的。

  2. 部分存储库(子目录)签出/签入。Mercurial和bzr不支持此功能，git的支持也有限。这在团队环境中很糟糕，但如果我想在我的家庭目录的另一台计算机上检查一些东西，这是非常宝贵的。

只是我的经验。

小开

以下是我对一些重复的问题被删除了关于Git vs. SVN(2009年9月)的回答的副本。

更好吗?除了通常的链接WhyGitIsBetterThanX之外，它们是不同的:

one是一个基于分支和标记的廉价复制的中央VCS 另一个(Git)是基于修订图的分布式VCS。 参见VCS的核心概念.

第一部分产生了一些错误的评论，假装这两个程序(SVN和Git)的基本目的是相同的，但它们的实现完全不同 为了澄清SVN和Git的根本区别，让我重新措辞:

  • SVN是第三个实现了revision control: RCS，然后是CVS，最后是SVN管理目录的版本化数据。SVN提供了VCS特性(标记和合并)，但它的标记只是一个目录副本(就像一个分支，只不过您“不应该”接触标记目录中的任何东西)，而且它的合并仍然很复杂，目前是基于添加的元数据来记住已经合并的内容。

  • Git是一个文件内容管理(一个用于合并文件的工具)，演变成一个真正的版本控制系统，基于提交的DAG (有向无环图)，其中分支是数据历史的一部分(而不是数据本身)，其中标签是真正的元数据。

说他们没有“根本”不同，因为你可以实现同样的事情，解决同样的问题，是……在很多层面上都是错误的。

  • 如果您有许多复杂的合并，那么使用SVN执行它们将会花费更长的时间，而且更容易出错。 如果你必须创建很多分支，你将需要管理它们并合并它们，Git比SVN更容易，特别是当涉及到大量文件时(速度变得很重要)
  • 如果您对正在进行的工作有部分合并，您将利用Git暂存区(索引)只提交您需要的部分，保存其余部分，然后转移到另一个分支。
  • 如果你需要离线开发……使用Git，你总是“在线”的，使用你自己的本地存储库，无论你想要遵循其他存储库的工作流程。

然而，对那个旧答案(已删除)的评论坚持认为:

VonC:你混淆了实现上的根本差异(差异是非常根本的，我们都清楚地同意这一点)和目的上的差异 它们都是用于相同目的的工具:这就是为什么许多以前使用SVN的团队能够相当成功地将其抛弃，转而使用Git的原因 如果它们不能解决相同的问题，可置换性将不存在

，我回答说:

< p > "可代换性”……有趣的术语(用于计算机编程).
当然，Git并不是SVN的子类型。< / p >

你可以用这两个工具实现相同的技术特性(标记、分支、合并)，但是Git不会妨碍你使用允许您专注于文件的内容，而不考虑工具本身。

你当然不能(总是)用Git替换SVN，“而不改变该程序的任何可取属性(正确性、执行的任务……)”。(这是对前面提到的可置换性定义的引用):

  • 一个是扩展的修订工具，另一个是真正的版本控制系统。
  • 一种适合小型到中型单片项目，具有简单的合并工作流和(不是太多)并行版本。SVN就足够了，您可能不需要所有Git特性。
    • 另一种允许基于多个组件(每个组件一次回购)的中型到大型项目，在复杂的合并工作流中在多个分支之间合并大量文件，分支中的并行版本，改造合并等等。你可以用SVN来做，但是你用Git会更好 SVN根本无法使用任何合并工作流管理任何规模的任何项目。李Git。< / >
同样，它们的性质根本不同(这会导致不同的实现，但这不是重点).
一个将修订控制视为目录和文件，另一个仅看到文件的内容(以至于空目录甚至不会在Git中注册!)< / p >

一般的最终目标可能是相同的，但您不能以相同的方式使用它们，也不能解决相同类型的问题(在范围或复杂性方面)。

小开

我已经使用SVN很长时间了，但是每当我使用Git时，我都觉得Git非常强大，轻量级，尽管有一点学习曲线，但它比SVN要好。

我所注意到的是，每个SVN项目，随着它的发展，都会变成一个非常大的项目，除非它被导出。其中，GIT项目(以及GIT数据)的大小非常轻。

在SVN中，我与从新手到专家的开发人员都打过交道，如果新手和中级开发人员为了重用一个文件夹而从另一个SVN项目复制文件夹，他们似乎会引入文件冲突。然而，我认为在Git中，你只需要复制文件夹就可以了，因为Git没有在所有子文件夹中引入. Git文件夹(就像SVN那样)。

在很长一段时间内处理了大量的SVN之后，我终于考虑将我和我的开发人员转移到Git，因为它很容易协作和合并工作，还有一个很大的优势是，本地副本的更改可以根据需要提交，然后最终推送到服务器上的分支，而不像SVN(我们必须不时地在服务器上的存储库中提交更改)。

谁能帮我决定我是否真的应该使用Git?

小开

在做了更多的研究，并审查了这个链接:https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(摘录如下):

    它快得令人难以置信。 我用过的其他SCM都跟不上它，我用过很多，包括Subversion、Perforce、darcs、BitKeeper、ClearCase和CVS
  • 它是完全分布的。 存储库所有者不能规定我如何工作。我可以在我的笔记本电脑上断开连接时创建分支并提交更改，然后稍后将其与任何数量的其他存储库同步
  • 同步可以发生在多种媒体上。 一个SSH通道，通过HTTP，通过WebDAV，通过FTP，或者通过发送电子邮件来保存要由消息的接收者应用的补丁。中央存储库不是必需的，但可以使用 分支甚至比在Subversion中更便宜。 创建分支就像将一个41字节的文件写入磁盘一样简单。删除分支就像删除那个文件一样简单 与Subversion不同，分支有完整的历史。 而不需要执行一个奇怪的副本并遍历副本。在使用Subversion时，我总是发现在分支创建之前查看分支上文件的历史记录很尴尬。@ #git: spearce:我不明白页面中关于SVN的一件事。我在SVN上创建了一个分支，在浏览历史记录时显示了分支
    • 中的一个文件 在Git中，分支合并更简单、更自动。 在Subversion中，您需要记住上一次合并的版本是什么，以便生成正确的合并命令。Git会自动执行这个操作，而且总是正确的。这意味着合并两个分支时出错的几率更小。 的分支合并被记录为正确历史的一部分 存储库。如果我将两个分支合并在一起，或者如果我将一个分支合并回它来自的主干中，这个合并操作将被记录为存储库历史的一部分，因为是我执行的，以及何时执行的。很难判断是谁执行了归并，因为它就在日志中。
  • 创建一个存储库是一个简单的操作: mkdir foo;cd foo;git init 就是这样。这意味着我现在要为所有东西创建一个Git存储库。我倾向于每个类使用一个存储库。大多数存储库的磁盘容量都在1mb以下，因为它们只存储课堂笔记、家庭作业和我的LaTeX答案 存储库的内部文件格式非常简单。 这意味着修复非常容易，但更好的是，因为它是如此简单，很难被损坏。我认为还没有人的Git存储库被破坏过。我看到过带有fsfs的Subversion自身损坏。我已经看到Berkley DB破坏自己太多次，相信我的代码到bdb后端Subversion.
    • Git的文件格式非常擅长压缩数据，尽管如此 这是一个非常简单的格式。Mozilla项目的CVS存储库大约有3gb;它在Subversion的fsfs格式中大约是12gb。在Git中大约是300mb

在阅读了所有这些之后，我确信Git是可行的方法(尽管存在一点学习曲线)。我也在Windows平台上使用过Git和SVN。

我很想听听其他人在读完上面的文章后会怎么说?

小开

这可以归结为:

你的发展是线性的吗?如果是这样，您应该坚持使用Subversion。

另一方面，如果您的开发不是线性的，这意味着您将需要为不同的更改创建分支，然后将这些更改合并回主开发线(Git称为主分支)，那么Git将为您做更多的工作。


提交答案