我应该使用SVN还是Git？[关闭]

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

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

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

同时，您可以在TortoiseGit和GitExtensions之间进行选择（如果您在自己的客户端GitHub上托管 “中央” git存储库-Windows的GitHub）。

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

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

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

我绝对会推荐git而不是subversion；它的用途更加广泛，并且可以以绝对无法实现的方式进行“离线开发”。它几乎可以在每个可以想象的平台上使用，并且具有比您可能会使用的更多的功能。

这是我对某些重复问题做出的答案的副本，此后便删除了有关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：您在实现方面存在根本的差异（差异是非常根本的，我们俩都明确同意这一点）。
它们都是用于同一目的的工具：这就是为什么许多以前使用SVN的团队都能够成功地将其转交给Git的原因。
如果他们不能解决相同的问题，那么这种可替代性将不存在。

，我回答了：

“可替换性” ...一个有趣的术语（在计算机编程中使用）。
当然，Git几乎不是SVN的子类型。

您可能同时实现了相同的技术功能（标签，分支，合并），但是Git并没有妨碍您，而是让您专注于文件的内容无需考虑工具本身就。

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

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

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

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

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

1. 大文件支持。除了代码之外，我还使用SVN来管理我的主目录。SVN是唯一不会使TrueCrypt文件阻塞的VCS（无论是否分布式）（如果还有另一个VCS有效处理500MB +文件，请更正我）。这是因为流比较比较（这是非常重要的一点）。Rsync是不可接受的，因为它不是2路的。

2. 部分存储库（子目录）检出/检入。Mercurial和bzr不支持此功能，而git的支持很有限。这在团队环境中是不好的，但是如果我想从主目录在另一台计算机上签出某项东西，这将是非常宝贵的。

只是我的经验。

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

（以下摘录）：

• 它的速度非常快。我使用过的其他SCM都无法跟上它，并且我使用了很多，包括Subversion，Perforce，darcs，BitKeeper，ClearCase和CVS。
• 它是完全分布式的。存储库所有者无法决定我的工作方式。我可以在断开与笔记本电脑的连接时创建分支并提交更改，然后将其与任意数量的其他存储库同步。
• 同步可以在许多媒体上发生。SSH通道，通过WebDAV通过HTTP，FTP或通过发送包含补丁的电子邮件发送，该补丁将由消息的接收者应用。中央存储库不是必需的，但可以使用。
• 分支甚至比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。

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

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

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

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

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

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

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

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

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

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

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

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

绝对可以svn，因为Windows充其量是世界上第二等的公民git（有关更多详细信息，请参见http://en.wikipedia.org/wiki/Git_(software)#Portability）。

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

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

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

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

目前，Git仅可通过Cygwin或MSYS在Windows上运行。Subversion从一开始就支持Windows。由于Windows的git解决方案可能适合您，因此可能会出现问题，因为大多数Git开发人员都使用Linux，并且从一开始就没有可移植性。目前，我希望在Windows下使用Subversion进行开发。几年后这可能无关紧要。

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

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

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

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

如今，相对于SVN，我更喜欢Git，但如果您来自SVN领域的CVS，则需要花费一些时间才能超过阈值。

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

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

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

我注意到的是，每个SVN项目都会随着其增长而变成一个很大的项目，除非将其导出。另外，GIT项目（以及Git数据）的大小非常轻。

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

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

有谁可以帮助我决定我是否应该真正使用Git？

归结为：

您的发展会线性吗？如果是这样，则应坚持使用Subversion。

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

你尝试过Bzr吗？

非常好，因为他们不喜欢市场上的其他东西，所以（由Ubuntu的人创建的）令人反感。

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

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

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

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

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

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

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