我已经使用Subversion几年了，在使用SourceSafe之后，我就是喜欢 Subversion。结合TortoiseSVN，我真的无法想象它会变得更好。
然而，越来越多的开发人员声称 Subversion 存在问题，我们应该转向新型分布式版本控制系统，例如Git。
Git 如何改进 Subversion？
问问题
914068 次
30 回答
547
Git并不比Subversion好。但也不差。这是不同的。
主要区别在于它是去中心化的。想象一下，您是一名在路上的开发人员，您在笔记本电脑上进行开发，并且您希望拥有源代码控制，这样您就可以回到 3 个小时。
使用 Subversion，您有一个问题：SVN 存储库可能位于您无法到达的位置（在您的公司中，并且您目前没有互联网），您无法提交。如果要复制代码，则必须逐字复制/粘贴它。
使用 Git，您就没有这个问题。您的本地副本是一个存储库，您可以提交它并获得源代码控制的所有好处。当您重新连接到主存储库时，您可以提交它。
起初这看起来不错，但请记住这种方法增加的复杂性。
Git 似乎是“新的、闪亮的、酷炫的”东西。这绝不是坏事（Linus 为 Linux Kernel 开发写它毕竟是有原因的），但我觉得很多人跳上“分布式源代码控制”火车只是因为它是新的并且是由 Linus Torvalds 编写的，实际上并没有知道为什么/如果它更好。
Subversion 有问题，但 Git、Mercurial、CVS、TFS 或其他什么也有。
编辑：所以这个答案现在已经有一年了，仍然会产生很多赞成票，所以我想我会添加更多解释。自撰写本文以来的最后一年，Git 获得了很多动力和支持，尤其是在 GitHub 等网站真正起飞之后。我现在同时使用 Git 和 Subversion，我想分享一些个人见解。
首先，在去中心化工作时，Git 一开始可能会让人感到困惑。什么是遥控器？以及如何正确设置初始存储库？是一开始就提出的两个问题，特别是与 SVN 的简单“svnadmin create”相比，Git 的“git init”可以带参数 --bare 和 --shared 这似乎是设置集中式的“正确”方式存储库。这是有原因的，但它增加了复杂性。“checkout”命令的文档对于转换的人来说非常混乱——“正确”的方式似乎是“git clone”，而“git checkout”似乎是切换分支。
当你去中心化时，Git 真的会发光。我家里有一台服务器，路上有一台笔记本电脑，而 SVN 在这里根本无法正常工作。使用 SVN，如果我没有连接到存储库，我将无法进行本地源代码控制（是的，我知道 SVK 或复制存储库的方法）。无论如何，对于 Git，这都是默认模式。虽然这是一个额外的命令（git commit 在本地提交，而 git push origin master 将 master 分支推送到名为“origin”的远程）。
如上所述：Git 增加了复杂性。创建存储库的两种模式，签出与克隆，提交与推送...您必须知道哪些命令在本地工作，哪些与“服务器”一起工作（我假设大多数人仍然喜欢中央“主存储库” ）。
此外，工具仍然不足，至少在 Windows 上是这样。是的，有一个 Visual Studio 插件，但我仍然使用 git bash 和 msysgit。
SVN 的优势在于它更易于学习：有你的存储库，所有对它的更改，如果你知道如何创建、提交和签出，并且你已经准备好并且可以稍后获取分支、更新等内容在。
Git 的优势在于，如果某些开发人员并不总是连接到主存储库，它会更适合。此外，它比 SVN 快得多。据我所知，分支和合并支持要好得多（这是意料之中的，因为这些是编写它的核心原因）。
这也解释了为什么它在 Internet 上引起了如此多的关注，因为 Git 非常适合开源项目：只需 Fork 它，将您的更改提交到您自己的 Fork，然后请原始项目维护者拉取您的更改。使用 Git，这很有效。真的，在 Github 上试试，很神奇。
我还看到了 Git-SVN 桥接器：中央存储库是一个 Subversion 存储库，但开发人员在本地使用 Git，然后桥接器将他们的更改推送到 SVN。
但即使有这么长的补充，我仍然坚持我的核心信息：Git 没有好坏之分，它只是不同。如果您需要“离线源代码管理”并且愿意花一些额外的时间来学习它，那就太棒了。但是，如果您有一个严格集中的源代码控制和/或因为您的同事不感兴趣而首先努力引入源代码控制，那么 SVN 的简单性和出色的工具（至少在 Windows 上）会大放异彩。
于 2008-08-03T22:45:44.533 回答
145
使用 Git，您几乎可以离线做任何事情，因为每个人都有自己的存储库。
创建分支和分支之间的合并非常容易。
即使您没有项目的提交权限，您仍然可以拥有自己的在线存储库，并为您的补丁发布“推送请求”。每个喜欢您的补丁的人都可以将它们拉入他们的项目，包括官方维护者。
分叉一个项目，修改它，然后继续合并来自 HEAD 分支的错误修复是微不足道的。
Git 适用于 Linux 内核开发人员。这意味着它非常快（必须如此），并且可以扩展到成千上万的贡献者。Git 使用的空间也更少（Mozilla 存储库的空间最多减少 30 倍）。
Git 非常灵活，非常 TIMTOWTDI（有不止一种方法可以做到）。你可以使用任何你想要的工作流程，Git 会支持它。
最后，还有GitHub，这是一个托管 Git 存储库的绝佳站点。
Git的缺点：
- 它更难学习，因为 Git 有更多的概念和更多的命令。
- 修订版没有 subversion 中的版本号
- 很多 Git 命令都是晦涩难懂的，而且错误信息对用户非常不友好
- 它缺乏一个好的 GUI（比如伟大的TortoiseSVN）
于 2008-08-04T00:24:15.940 回答
110
其他答案很好地解释了 Git 的核心功能（很棒）。但是还有很多小方法可以让 Git 表现得更好，并帮助我的生活更加理智。以下是一些小事：
- Git 有一个“干净”的命令。SVN 迫切需要这个命令，考虑到它会多频繁地在您的磁盘上转储额外文件。
- Git 有 'bisect' 命令。这真好。
- SVN 在每个文件夹中创建 .svn 目录（Git 只创建一个.git 目录）。您编写的每个脚本和执行的每个 grep 都需要编写以忽略这些 .svn 目录。您还需要一个完整的命令（“svn export”）来获得文件的健全副本。
- 在 SVN 中，每个文件和文件夹都可以来自不同的修订版或分支。起初，拥有这种自由听起来不错。但这实际上意味着您的本地结帐有上百万种不同的方式可以完全搞砸。（例如，如果“svn switch”中途失败，或者输入错误的命令）。最糟糕的是：如果您遇到一些文件来自一个地方，而其中一些来自另一个地方的情况，“svn 状态”会告诉您一切正常。您需要在每个文件/目录上执行“svn info”以发现事情有多奇怪。如果“git status”告诉你事情很正常，那么你可以相信事情真的很正常。
- 每当您移动或删除某些内容时，您都必须告诉 SVN。Git 会弄清楚的。
- 在 Git 中忽略语义更容易。如果您忽略一个模式（例如 *.pyc），它将被所有子目录忽略。（但如果你真的想忽略一个目录的东西，你可以）。使用 SVN，似乎没有简单的方法可以忽略所有子目录中的模式。
- 另一个涉及忽略文件的项目。Git 可以进行“私人”忽略设置（使用文件 .git/info/exclude），这不会影响其他任何人。
于 2008-09-26T00:18:38.620 回答
56
“为什么 Git 比 X 更好”概述了 Git 与其他 SCM 相比的各种优缺点。
简要地：
- Git 跟踪内容而不是文件
- 分支是轻量级的，合并很容易，我的意思是非常容易。
- 它是分布式的，基本上每个存储库都是一个分支。在我看来，与 Subversion 相比，并发和协作开发要容易得多。它还使离线开发成为可能。
- 它不强加任何工作流，如上面链接的网站上所见，Git 有许多工作流可能。Subversion 风格的工作流程很容易被模仿。
- Git 存储库的文件大小比 Subversion 存储库小得多。只有一个“.git”目录，而不是几十个“.svn”存储库（注意 Subversion 1.7 和更高版本现在使用像 Git 这样的单个目录。）
- 暂存区很棒，它允许您查看您将提交的更改、提交部分更改并执行各种其他操作。
- 当您进行“混乱”开发时，或者只是想在您仍在处理其他事情（在不同的分支上）时修复错误时，存储是非常宝贵的。
- 您可以重写历史，这对于准备补丁集和修复错误非常有用（在您发布提交之前）
- ……还有更多。
有一些缺点：
- 还没有很多好的GUI。它是新的，Subversion 已经存在了很长时间，所以这是很自然的，因为有一些接口正在开发中。一些不错的包括TortoiseGit和GitHub for Mac。
目前无法部分签出/克隆存储库（我读到它正在开发中）。但是，有子模块支持。Git 1.7+ 支持稀疏检出。- 即使我没有发现这种情况（大约一年前），它也可能更难学习。Git 最近改进了它的界面并且非常用户友好。
在最简单的用法中，Subversion 和 Git 几乎相同。之间没有太大区别：
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
和
git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
Git 真正闪耀的地方是分支和与其他人一起工作。
于 2009-02-10T04:18:46.543 回答
54
于 2008-08-03T22:44:26.203 回答
26
嗯，已经分发了。基准测试表明它要快得多（考虑到它的分布式特性，差异和日志等操作都是本地的，所以在这种情况下它当然要快得多），并且工作文件夹更小（这仍然让我大吃一惊）。
当您在处理 subversion 或任何其他客户端/服务器修订控制系统时，您实际上是通过签出修订在您的机器上创建工作副本。这代表了存储库外观的时间快照。您通过更新更新工作副本，并通过提交更新存储库。
使用分布式版本控制，您没有快照，而是整个代码库。想与 3 个月大的版本进行比较吗？没问题，3 个月大的版本仍在您的计算机上。这不仅意味着事情要快得多，而且如果您与中央服务器断开连接，您仍然可以执行许多您习惯的操作。换句话说，您不仅拥有给定版本的快照，还拥有整个代码库。
你会认为 Git 会占用你硬盘上的大量空间，但从我见过的几个基准测试来看，它实际上占用的空间更少。不要问我怎么做。我的意思是，它是由 Linus 构建的，我猜他对文件系统略知一二。
于 2008-08-03T22:47:42.703 回答
22
我喜欢 DVCS 的要点是：
- 你可以犯下坏事。没关系，因为在您发布之前，其他人不会看到它们。发布时间与提交时间不同。
- 因此，您可以更频繁地提交。
- 您可以合并完整的功能。此功能将有自己的分支。此分支的所有提交都将与此功能相关。您可以使用 CVCS 执行此操作，但默认使用 DVCS。
- 您可以搜索您的历史记录（查找功能何时更改）
- 如果有人搞砸了主存储库，您可以撤消拉取操作，您不需要修复错误。只需清除合并。
- 当您需要在任何目录中进行源代码控制时，请执行以下操作：git init。您可以提交、撤消更改等...
- 它很快（即使在 Windows 上）
一个相对大的项目的主要原因是第 3 点创造的更好的沟通。其他都是不错的奖励。
于 2008-09-04T11:06:59.397 回答
15
有趣的是：我在 Subversion Repos 中托管项目，但通过 Git Clone 命令访问它们。
尽管 Google Code 原生使用 Subversion，但您可以在开发过程中轻松使用 Git。搜索“git svn”表明这种做法很普遍，我们也鼓励您尝试一下。
在 Svn 存储库上使用 Git 给我带来了好处：
- 我可以在多台机器上进行分布式工作，向它们提交和拉取
- 我有一个中央
backup/publicsvn 存储库供其他人查看 - 他们可以自由地为自己使用 Git
于 2008-10-02T13:05:58.340 回答
11
这里的所有答案都符合预期，以程序员为中心，但是如果您的公司在源代码之外使用修订控制会发生什么？有很多不是源代码的文档可以从版本控制中受益，并且应该靠近代码而不是在另一个 CMS 中。大多数程序员不会孤立地工作——我们作为团队的一部分为公司工作。
考虑到这一点，比较 Subversion 和 git 在客户端工具和培训方面的易用性。我看不到任何分布式修订控制系统将更容易使用或向非程序员解释的场景。我很想被证明是错误的，因为这样我就能够评估 git 并且实际上希望它被那些需要版本控制但不是程序员的人所接受。
即便如此，如果管理层问我们为什么要从集中式版本控制系统转向分布式版本控制系统，我也很难给出诚实的答案，因为我们不需要它。
免责声明：我很早就对 Subversion 产生了兴趣（大约在 v0.29 左右），所以显然我有偏见，但是从那时起我工作的公司都从我的热情中受益，因为我鼓励并支持它的使用。我怀疑这就是大多数软件公司的情况。有这么多程序员加入 git 的潮流，我想知道有多少公司会错过在源代码之外使用版本控制的好处？即使您为不同的团队使用不同的系统，您也会错过一些好处，例如（统一的）问题跟踪集成，同时增加了维护、硬件和培训要求。
于 2009-10-13T07:01:50.840 回答
8
SubVersion 让我恼火的一件事是它在项目的每个目录中都放置了自己的文件夹，而 git 只在根目录中放置了一个文件夹。这没什么大不了的，但是像这样的小事情加起来。
当然，SubVersion 有 Tortoise，[通常] 非常好。
于 2008-08-22T15:24:44.907 回答
8
David Richards WANdisco 关于 Subversion / GIT 的博客
GIT 的出现带来了一批 DVCS 原教旨主义者——“Gitterons”——他们认为除了 GIT 之外的任何东西都是垃圾。Gitterons 似乎认为软件工程发生在他们自己的岛屿上，并且经常忘记大多数组织并不专门雇用高级软件工程师。没关系，但这不是市场其他人的想法，我很高兴证明这一点：GIT，最后看起来不到 3% 的市场，而 Subversion 拥有大约 500 万用户和大约一半的市场整体市场。
我们看到的问题是 Gitterons 正在向 Subversion 开火（廉价）。像“颠覆是如此[缓慢/蹩脚/限制/闻起来不好/以一种有趣的方式看着我]的推文，现在我有GIT和[我生活中的一切正常/我妻子怀孕了/之后我有了女朋友30 年的尝试/我在二十一点桌上赢得了六次]。你得到图片。
于 2010-09-17T18:22:30.390 回答
7
Git 还使分支和合并变得非常容易。Subversion 1.5 刚刚添加了合并跟踪，但 Git 仍然更好。使用 Git 分支非常快速且便宜。它使为每个新功能创建一个分支更加可行。哦，与 Subversion 相比，Git 存储库在存储空间方面非常有效。
于 2008-08-09T03:22:14.510 回答
6
这一切都与做某事所需的易用性/步骤有关。
如果我在我的 PC/笔记本电脑上开发单个项目，git 更好，因为它更容易设置和使用。您不需要服务器，也不需要在进行合并时继续输入存储库 URL。
如果只有 2 个人，我会说 git 也更容易，因为你可以互相推拉。
不过，一旦你超越了这一点，我就会去颠覆，因为那时你需要设置一个“专用”服务器或位置。
使用 git 和使用 SVN 一样可以做到这一点，但是 git 的好处被需要执行额外的步骤来与中央服务器同步所抵消。在 SVN 中，您只需提交即可。在 git 中，你必须先 git commit，然后再 git push。额外的步骤变得烦人只是因为你最终做了这么多。
SVN 还具有更好的 GUI 工具的好处，但是 git 生态系统似乎正在迅速赶上，所以从长远来看，我不会担心这一点。
于 2008-08-03T23:38:05.113 回答
5
一般来说，Git 和 DVCS 非常适合开发人员相互独立地进行大量编码，因为每个人都有自己的分支。但是，如果您需要其他人的更改，她必须提交到她的本地存储库，然后她必须将该更改集推送给您，或者您必须从她那里拉取它。
我自己的推理也让我认为，如果你做集中发布之类的事情，DVCS 会让 QA 和发布管理变得更加困难。必须有人负责从其他人的存储库中进行推送/拉取，解决在初始提交时间之前已经解决的任何冲突，然后进行构建，然后让所有其他开发人员重新同步他们的存储库。
当然，所有这些都可以通过人工流程来解决。DVCS 刚刚打破了集中版本控制修复的一些问题，以提供一些新的便利。
于 2008-08-03T23:08:23.580 回答
5
我喜欢 Git，因为它实际上可以帮助大中型团队中的开发人员与开发人员进行交流。作为一个分布式版本控制系统，通过其推/拉系统，它帮助开发人员创建一个源代码生态系统，帮助管理大量开发人员在单个项目上工作。
例如，假设您信任 5 个开发人员，并且只从他们的存储库中提取代码。这些开发人员中的每一个都有自己的信任网络，他们从中提取代码。因此，开发基于开发人员的信任结构，其中代码责任在开发社区之间共享。
当然，这里的其他答案中提到了其他好处。
于 2008-10-05T16:52:34.693 回答
4
一些答案暗示了这些，但我想明确指出两点：
1) 进行选择性提交的能力（例如，git add --patch）。如果您的工作目录包含不属于同一逻辑更改的多个更改，Git 可以很容易地进行仅包含部分更改的提交。使用 Subversion，这很困难。
2) 在不公开更改的情况下提交的能力。在 Subversion 中，任何提交都是立即公开的，因此是不可撤销的。这极大地限制了开发者“早提交，常提交”的能力。
Git 不仅仅是一个 VCS。它也是开发补丁的工具。Subversion 只是一个 VCS。
于 2009-08-07T14:59:17.853 回答
4
我认为 Subversion 很好.. 直到您开始合并.. 或做任何复杂的事情.. 或做任何 Subversion 认为复杂的事情（例如查询哪些分支与特定文件混淆，更改实际来自何处，检测复制和粘贴， ETC）...
我不同意获胜的答案，说 GIT 的主要好处是离线工作 - 它当然很有用，但它更像是我的用例的额外内容。SVK 也可以离线工作，我仍然毫无疑问将学习时间投入到哪一个上）。
只是它非常强大和快速，而且——在习惯了这些概念之后——非常有用（是的，从这个意义上说：用户友好）。
有关合并故事的更多详细信息，请参见： Using git-svn (or similar) *just* to help out with an svn merge?
于 2010-07-27T15:40:33.973 回答
3
由于它不需要经常与中央服务器通信，几乎每个命令都在不到一秒的时间内运行（显然 git push/pull/fetch 速度较慢，因为它们必须初始化 SSH 连接）。分支要容易得多（一个简单的分支命令，一个简单的合并命令）
于 2008-08-30T12:01:09.527 回答
3
我非常喜欢能够在 Git 中管理我的源代码的本地分支，而不会弄乱中央存储库的水。在许多情况下，我会从 Subversion 服务器签出代码并运行本地 Git 存储库，以便能够做到这一点。初始化 Git 存储库不会因为到处都是一堆烦人的 .svn 文件夹而污染文件系统，这也很棒。
并且就 Windows 工具支持而言，TortoiseGit 处理基础非常好，但我仍然更喜欢命令行，除非我想查看日志。我真的很喜欢 Tortoise{Git|SVN} 在阅读提交日志时的帮助方式。
于 2010-02-10T22:54:35.410 回答
3
这是一个错误的问题。关注 git 的缺点并就为什么 subversion 表面上更好，至少对于某些用例来说，这太容易了。git 最初被设计为一个低级版本控制构造集并具有巴洛克式的面向 linux 开发人员的界面，这一事实使得圣战更容易获得牵引力和合法性。Git 支持者用数以百万计的工作流程优势来敲鼓，svn 的人宣称这是不必要的。很快，整个辩论就被定格为集中式与分布式，这符合企业 svn 工具社区的利益。这些公司通常会发表关于颠覆在企业中的优势的最有说服力的文章，
但问题是：Subversion 是一个架构死胡同。
虽然你可以很容易地使用 git 并构建一个集中的颠覆替代品，尽管 svn 存在的时间是它的两倍多，但它甚至无法像在 git 中那样在任何地方实现基本的合并跟踪。造成这种情况的一个基本原因是使分支与目录相同的设计决策。我不知道他们最初为什么要这样做，这确实使部分结帐变得非常简单。不幸的是，它也使得无法正确跟踪历史。现在显然你应该使用颠覆存储库布局约定将分支与常规目录分开，并且 svn 使用一些启发式方法使事情适用于日常用例。但这一切都只是掩盖了一个非常糟糕和限制性的低级设计决策。能够进行存储库方式的差异（而不是目录方式的差异）是版本控制系统的基本和关键功能，并且大大简化了内部结构，从而可以在其之上构建更智能和有用的功能。您可以看到扩展颠覆所付出的努力，但在合并解析等基本操作方面，它与当前的现代 VCS 作物相差甚远。
现在，对于那些仍然相信 Subversion 在可预见的未来足够好的人来说，这是我发自内心的不可知论的建议：
Subversion 永远赶不上从 RCS 和 CVS 的错误中吸取教训的较新品种的 VCS；除非他们从头开始重新构建存储库模型，否则这在技术上是不可能的，但它不会真的是 svn 吗？无论您认为自己不具备现代 VCS 的功能多少，您的无知都无法保护您免受 Subversion 的陷阱，其中许多情况在其他系统中是不可能或容易解决的。
一个解决方案的技术劣势像 svn 一样清晰，这是极其罕见的，当然我永远不会对 win-vs-linux 或 emacs-vs-vi 发表这样的看法，但在这种情况下它是如此清晰，源代码控制是开发人员武器库中的一个基本工具，我觉得必须明确说明。不管出于组织原因使用 svn 的要求如何，我恳请所有 svn 用户不要让他们的逻辑思维构建错误的信念，即更现代的 VCS 仅对大型开源项目有用。无论您的开发工作的性质如何，如果您是一名程序员，那么如果您学习如何使用设计更好的 VCS，无论是 Git、Mercurial、Darcs 还是许多其他工具，您都会成为一名更高效的程序员。
于 2011-05-29T17:30:50.897 回答
2
Subversion 非常易于使用。在过去的几年中，我从未发现任何问题或某些事情没有按预期工作。还有很多优秀的 GUI 工具，对 SVN 集成的支持很大。
使用 Git，您可以获得更灵活的 VCS。您可以像使用 SVN 一样将它与远程存储库一起使用，您可以在其中提交所有更改。但是您也可以大部分时间离线使用它，并且不时地将更改推送到远程存储库。但 Git 更复杂，学习曲线也更陡峭。我第一次发现自己犯了错误的分支，间接创建分支或收到错误消息，但关于错误的信息不多，我必须用谷歌搜索以获得更好的信息。一些简单的事情，比如替换标记 ($Id$) 不起作用，但 GIT 有一个非常灵活的过滤和挂钩机制来合并自己的脚本，所以你得到你需要的所有东西，但它需要更多的时间和阅读文档;)
如果您主要使用本地存储库脱机工作，那么如果本地计算机上丢失了某些内容，则没有备份。使用 SVN，您主要使用远程存储库，这也是您在另一台服务器上备份的同时...... Git 可以以相同的方式工作，但这不是 Linus 拥有类似 SVN2 的主要目标。它是为 Linux 内核开发者和分布式版本控制系统的需要而设计的。
Git 比 SVN 更好吗？只需要一些版本历史记录和备份机制的开发人员使用 SVN 可以过上轻松愉快的生活。经常使用分支、同时测试更多版本或主要离线工作的开发人员可以从 Git 的功能中受益。有一些非常有用的功能，例如 SVN 所没有的存储功能，可以让生活更轻松。但另一方面，并非所有人都需要所有功能。所以我看不到SVN的死。
Git 需要一些更好的文档，并且错误报告必须更有帮助。此外，现有的有用 GUI 也很少。这次我只找到了 1 个支持大多数 Git 功能（git-cola）的 Linux 图形用户界面。Eclipse 集成正在运行，但尚未正式发布，也没有官方更新站点（只有一些外部更新站点，定期从主干http://www.jgit.org/updates构建）所以这是当今使用 Git 的最首选方式是命令行。
于 2009-10-13T13:14:45.567 回答
2
SourceGear 的Eric Sink撰写了关于分布式和非分布式版本控制系统之间差异的系列文章。他比较了最流行的版本控制系统的优缺点。非常有趣的阅读。
文章可以在他的博客www.ericsink.com上找到：
于 2009-10-13T13:36:01.670 回答
2
对于寻找良好 Git GUI 的人来说，Syntevo SmartGit可能是一个不错的解决方案。我认为它是专有的，但可免费用于非商业用途，可在 Windows/Mac/Linux 上运行，甚至使用某种 git-svn 桥支持 SVN。
于 2011-03-09T14:05:56.953 回答
1
首先，并发版本控制似乎是一个容易解决的问题。根本不是。反正...
SVN 非常不直观。吉特更糟糕。[讽刺推测] 这可能是因为喜欢并发版本控制等难题的开发人员对制作好的 UI 没有太大兴趣。[/讽刺猜测]
SVN 支持者认为他们不需要分布式版本控制系统。我也是这么想的。但现在我们只使用 Git，我相信。现在版本控制适用于我和团队/项目，而不仅仅是为项目工作。当我需要分支时，我会分支。有时它是一个分支，在服务器上有相应的分支，有时它没有。更不用说我必须研究的所有其他优点（部分归功于现代版本控制系统 UI 的神秘和荒谬的缺乏）。
于 2010-01-03T12:45:36.960 回答
1
Windows 中的 Git 现在得到了很好的支持。
查看 GitExtensions = http://code.google.com/p/gitextensions/
和手册以获得更好的 Windows Git 体验。
于 2010-02-10T16:29:29.163 回答
1
http://subversion.wandisco.com/component/content/article/1/40.html
我认为在开发人员中说 SVN Vs 是相当安全的。Git 争论已经有一段时间了，每个人都对哪个更好有自己的看法。这甚至在我们 2010 年及以后的 Subversion 网络研讨会期间的问题中提出。
我们的开源总监兼 Subversion 公司总裁 Hyrum Wright 谈到了 Subversion 和 Git 以及其他分布式版本控制系统 (DVCS) 之间的差异。
他还谈到了 Subversion 即将发生的变化，例如下一代工作副本 (WC-NG)，他认为这将导致许多 Git 用户转换回 Subversion。
观看他的视频，并通过在此博客上发表评论或在我们的论坛上发帖告诉我们您的想法。注册很简单，只需片刻！
于 2010-02-10T18:51:32.180 回答
1
我最近一直住在 Git 领域，我喜欢将它用于个人项目，但我还不能将工作项目从 Subversion 切换到它，因为员工的想法发生了变化，而且没有任何紧迫的好处。此外，我们内部运行的最大项目非常依赖svn:externals，据我目前所见，它在 Git 中并不能很好地无缝运行。
于 2010-04-25T21:35:23.513 回答
1
为什么我认为 Subversion 比 Git 更好（至少对于我从事的项目而言），主要是因为它的可用性和更简单的工作流程：
http://www.databasesandlife.com/why-subversion-is-better-than-git/
于 2010-10-22T16:25:05.737 回答