为什么 Git 比 Subversion 好？

Why is Git better than Subversion?

提问by Ben Mills

I've been using Subversionfor a few years and after using SourceSafe, I just love Subversion. Combined with TortoiseSVN, I can't really imagine how it could be any better.

我已经使用Subversion几年了，在使用SourceSafe 之后，我就喜欢 Subversion。结合TortoiseSVN，我真的无法想象它会如何变得更好。

Yet there's a growing number of developers claiming that Subversion has problems and that we should be moving to the new breed of distributed version control systems, such as Git.

然而，越来越多的开发人员声称 Subversion 存在问题，我们应该转向新的分布式版本控制系统，例如Git。

How does Git improve upon Subversion?

Git 如何改进 Subversion？

回答by Michael Stum

Git is not better than Subversion. But is also not worse. It's different.

Git 并不比 Subversion 好。但也不差。这是不同的。

The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.

关键的区别在于它是去中心化的。想象一下，您是一名在路上的开发人员，您在笔记本电脑上进行开发，并且想要进行源代码控制，以便您可以返回 3 个小时。

With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.

使用 Subversion，您会遇到一个问题：SVN 存储库可能位于您无法到达的位置（在您的公司中，并且您目前没有互联网），您无法提交。如果你想复制你的代码，你必须从字面上复制/粘贴它。

With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.

有了 Git，你就没有这个问题了。您的本地副本是一个存储库，您可以提交它并获得源代码控制的所有好处。当您重新连接到主存储库时，您可以对其进行提交。

This looks good at first, but just keep in mind the added complexity to this approach.

这起初看起来不错，但请记住这种方法增加的复杂性。

Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.

Git 似乎是“新的、闪亮的、酷的”东西。这绝不是坏事（毕竟 Linus 为 Linux 内核开发编写它是有原因的），但我觉得很多人跳上“分布式源代码控制”火车只是因为它是新的并且是由 Linus Torvalds 编写的，实际上并没有知道为什么/是否更好。

Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.

Subversion 有问题，但 Git、Mercurial、CVS、TFS 或其他任何东西也有问题。

Edit:So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.

编辑：所以这个答案现在已经有一年了，仍然会产生很多赞成票，所以我想我会添加一些更多的解释。在撰写本文后的去年，Git 获得了很多动力和支持，尤其是像 GitHub 这样的网站真正起飞之后。我现在同时使用 Git 和 Subversion，我想分享一些个人见解。

First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "git init" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.

首先，在去中心化工作时，Git 一开始可能真的很混乱。什么是遥控器？以及如何正确设置初始存储库？是一开始就出现的两个问题，尤其是对比SVN简单的“svnadmin create”，Git的“git init”可以带参数--bare和--shared，这似乎是设置集中式的“正确”方式存储库。这是有原因的，但它增加了复杂性。“checkout”命令的文档对于转换的人来说非常混乱——“正确”的方式似乎是“git clone”，而“git checkout”似乎是切换分支。

Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").

当你去中心化时，Git 真的很闪耀。我家里有一台服务器，路上有一台笔记本电脑，而 SVN 在这里根本无法正常工作。使用 SVN，如果我没有连接到存储库，我将无法进行本地源代码控制（是的，我知道 SVK 或复制存储库的方法）。无论如何，对于 Git，这是默认模式。这是一个额外的命令（git commit 在本地提交，而 git push origin master 将 master 分支推送到名为“origin”的远程）。

As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").

如上所述：Git 增加了复杂性。创建存储库的两种模式，签出与克隆，提交与推送……您必须知道哪些命令在本地工作，哪些与“服务器”一起工作（我假设大多数人仍然喜欢中央“主存储库” ）。

Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.

此外，工具仍然不足，至少在 Windows 上。是的，有一个 Visual Studio AddIn，但我仍然使用 git bash 和 msysgit。

SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.

SVN 的优势在于它更容易学习：如果你知道如何创建、提交和检出并且你准备好开始并且可以在以后选择分支、更新等内容，那么就有你的存储库，对它的所有更改在。

Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).

Git 的优势在于它更适合某些开发人员并不总是连接到主存储库的情况。此外，它比SVN快得多。据我所知，分支和合并支持要好得多（这是意料之中的，因为这些是编写它的核心原因）。

This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.

这也解释了为什么它在互联网上获得如此多的关注，因为 Git 非常适合开源项目：只需将它分叉，将您的更改提交到您自己的 Fork，然后让原始项目维护者拉取您的更改。使用 Git，这很有效。真的，在 Github 上尝试一下，这很神奇。

What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.

我还看到了 Git-SVN 桥：中央存储库是一个 Subversion 存储库，但开发人员在本地使用 Git，然后桥将他们的更改推送到 SVN。

But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.

但即使添加了这个冗长的内容，我仍然坚持我的核心信息：Git 没有更好或更坏，它只是不同。如果您需要“离线源代码控制”并且愿意花一些额外的时间来学习它，那就太棒了。但是，如果您有一个严格集中的源代码控制和/或因为您的同事不感兴趣而一开始就努力引入源代码控制，那么 SVN 的简单性和出色的工具（至少在 Windows 上）会大放异彩。

回答by Michiel de Mare

With Git, you can do practically anything offline, because everybody has their own repository.

使用 Git，您几乎可以离线做任何事情，因为每个人都有自己的存储库。

Making branches and merging between branches is really easy.

创建分支并在分支之间合并非常容易。

Even if you don't have commit rights for a project, you can still have your own repository online, and publish "push requests" for your patches. Everybody who likes your patches can pull them into their project, including the official maintainers.

即使您没有项目的提交权限，您仍然可以在线拥有自己的存储库，并为您的补丁发布“推送请求”。喜欢你的补丁的每个人都可以将它们拉入他们的项目，包括官方维护者。

It's trivial to fork a project, modify it, and still keep merging in the bugfixes from the HEAD branch.

fork 一个项目，修改它，并且仍然继续合并来自 HEAD 分支的错误修复是微不足道的。

Git works for the Linux kernel developers. That means it is really fast (it has to be), and scales to thousands of contributors. Git also uses less space (up to 30 times less space for the Mozilla repository).

Git 适用于 Linux 内核开发人员。这意味着它非常快（必须如此），并且可以扩展到成千上万的贡献者。Git 还使用更少的空间（Mozilla 存储库的空间最多减少 30 倍）。

Git is very flexible, very TIMTOWTDI (There is more than one way to do it). You can use whatever workflow you want, and Git will support it.

Git 非常灵活，非常TIMTOWTDI（有不止一种方法可以做到）。你可以使用任何你想要的工作流，Git 会支持它。

Finally, there's GitHub, a great site for hosting your Git repositories.

最后，还有GitHub，这是一个托管 Git 存储库的绝佳站点。

Drawbacks of Git:

Git的缺点：

• it's much harder to learn, because Git has more concepts and more commands.
• revisions don't have version numbers like in subversion
• many Git commands are cryptic, and error messages are very user-unfriendly
• it lacks a good GUI (such as the great TortoiseSVN)

• 学习起来要困难得多，因为 Git 有更多的概念和更多的命令。
• 修订没有像 subversion 那样的版本号
• 许多 Git 命令都很神秘，而且错误信息对用户非常不友好
• 它缺乏良好的图形用户界面（例如伟大的TortoiseSVN）

回答by andy

Other answers have done a good job of explaining the core features of Git (which are great). But there's also so many littleways that Git behaves better and helps keep my life more sane. Here are some of the little things:

其他答案在解释 Git 的核心功能方面做得很好（很棒）。但是也有很多小方法可以让 Git 表现得更好，并帮助我保持理智。以下是一些小事：

1. Git has a 'clean' command. SVN desperately needs this command, considering how frequently it will dump extra files on your disk.
2. Git has the 'bisect' command. It's nice.
3. SVN creates .svn directories in every single folder (Git only creates one.git directory). Every script you write, and every grep you do, will need to be written to ignore these .svn directories. You also need an entire command ("svn export") just to get a sane copy of your files.
4. In SVN, each file & folder can come from a different revision or branch. At first, it sounds nice to have this freedom. But what this actually means is that there is a million different ways for your local checkout to be completely screwed up. (for example, if "svn switch" fails halfway through, or if you enter a command wrong). And the worst part is: if you ever get into a situation where some of your files are coming from one place, and some of them from another, the "svn status" will tell you that everything is normal. You'll need to do "svn info" on each file/directory to discover how weird things are. If "git status" tells you that things are normal, then you can trust that things really are normal.
5. You have to tell SVN whenever you move or delete something. Git will just figure it out.
6. Ignore semantics are easier in Git. If you ignore a pattern (such as *.pyc), it will be ignored for allsubdirectories. (But if you really want to ignore something for just one directory, you can). With SVN, it seems that there is no easy way to ignore a pattern across all subdirectories.
7. Another item involving ignore files. Git makes it possible to have "private" ignore settings (using the file .git/info/exclude), which won't affect anyone else.

1. Git 有一个“干净”的命令。考虑到它在磁盘上转储额外文件的频率，SVN 迫切需要这个命令。
2. Git 有 'bisect' 命令。这真好。
3. SVN 在每个文件夹中创建 .svn 目录（Git 只创建一个.git 目录）。您编写的每个脚本以及您执行的每个 grep 都需要编写以忽略这些 .svn 目录。您还需要一个完整的命令（“svn export”）才能获得文件的完整副本。
4. 在 SVN 中，每个文件和文件夹都可以来自不同的修订版或分支。起初，拥有这种自由听起来不错。但这实际上意味着您的本地结账有数百万种不同的方式可以完全搞砸。（例如，如果“svn switch”中途失败，或者您输入了错误的命令）。最糟糕的是：如果您遇到某些文件来自一个地方而其中一些来自另一个地方的情况，“svn 状态”会告诉您一切正常。您需要在每个文件/目录上执行“svn info”以发现事情有多么奇怪。如果“git status”告诉您一切正常，那么您可以相信事情确实是正常的。
5. 每当您移动或删除某些内容时，您都必须告诉 SVN。Git 会想出来的。
6. 在 Git 中忽略语义更容易。如果您忽略某个模式（例如 *.pyc），则所有子目录都将忽略该模式。（但如果您真的只想忽略一个目录的某些内容，则可以）。使用 SVN，似乎没有简单的方法可以忽略所有子目录中的模式。
7. 另一个涉及忽略文件的项目。Git 使“私有”忽略设置成为可能（使用文件 .git/info/exclude），这不会影响其他任何人。

回答by sebnow

"Why Git is Better than X" outlines the various pros and cons of Git vs other SCMs.

“为什么 Git 比 X 好”概述了 Git 与其他 SCM 的各种优缺点。

Briefly:

简要地：

• Git tracks content rather than files
• Branches are lightweightand merging is easy, and I mean really easy.
• It's distributed, basically every repository is a branch. It's much easier to develop concurrently and collaboratively than with Subversion, in my opinion. It also makes offlinedevelopment possible.
• It doesn't impose any workflow, as seen on the above linked website, there are many workflows possible with Git. A Subversion-style workflow is easily mimicked.
• Git repositories are much smaller in file sizethan Subversion repositories. There's only one ".git" directory, as opposed to dozens of ".svn" repositories (note Subversion 1.7 and higher now uses a single directorylike Git.)
• The stagingarea is awesome, it allows you to see the changes you will commit, commit partial changes and do various other stuff.
• Stashingis invaluable when you do "chaotic" development, or simply want to fix a bug while you're still working on something else (on a different branch).
• You can rewrite history, which is great for preparing patch sets and fixing your mistakes (beforeyou publish the commits)
• … and a lotmore.

• Git 跟踪内容而不是文件
• 分支是轻量级的，合并很容易，我的意思是真的很容易。
• 它是分布式的，基本上每个存储库都是一个分支。在我看来，并发和协作开发比使用 Subversion 容易得多。它还使离线开发成为可能。
• 它不强加任何工作流程，如上面链接的网站所示，Git 有许多可能的工作流程。很容易模仿 Subversion 风格的工作流程。
• Git 存储库的文件大小比 Subversion 存储库小得多。只有一个“.git”目录，而不是几十个“.svn”存储库（注意 Subversion 1.7 和更高版本现在使用一个单一的目录，如 Git。）
• 该临时区域是真棒，它可以让你看到你将提交更改，提交局部修改和做各种其他的东西。
• 当您进行“混乱”开发时，或者只是想在您仍在处理其他事情（在不同的分支上）时修复错误时，存储是非常宝贵的。
• 您可以重写历史记录，这对于准备补丁集和修复错误非常有用（在您发布提交之前）
• ...还有很多更。

There are some disadvantages:

有一些缺点：

• There aren't many good GUIs for it yet. It's new and Subversion has been around for a lot longer, so this is natural as there are a few interfaces in development. Some good ones include TortoiseGitand GitHub for Mac.
• Partial checkouts/clones of repositories are not possible at the moment (I read that it's in development). However, there is submodule support.Git 1.7+ supports sparse checkouts.
• It might be harder to learn, even though I did not find this to be the case (about a year ago). Git has recently improved its interface and is quite user friendly.

• 目前还没有很多好的 GUI。它是新的并且 Subversion 已经存在了很长时间，所以这是很自然的，因为有一些接口正在开发中。一些不错的包括TortoiseGit和GitHub for Mac。
• 目前无法部分签出/克隆存储库（我读到它正在开发中）。但是，有子模块支持。Git 1.7+ 支持稀疏结帐。
• 可能更难学习，即使我没有发现这种情况（大约一年前）。Git 最近改进了它的界面并且非常用户友好。

In the most simplistic usage, Subversion and Git are pretty much the same. There isn't much difference between:

在最简单的用法中，Subversion 和 Git 几乎相同。之间没有太大区别：

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

and

和

git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Where Git really shines is branching and working with other people.

Git 真正闪耀的地方是分支和与其他人一起工作。

回答by ESV

Google Tech Talk: Linus Torvalds on git

Google 技术讲座：Git 上的 Linus Torvalds

http://www.youtube.com/watch?v=4XpnKHJAok8

http://www.youtube.com/watch?v=4XpnKHJAok8

The Git Wiki's comparison page

Git Wiki 的比较页面

http://git.or.cz/gitwiki/GitSvnComparsion

http://git.or.cz/gitwiki/GitSvnComparsion

回答by Karl Seguin

Well, it's distributed. Benchmarks indicate that it's considerably faster (given its distributed nature, operations like diffs and logs are all local so of course it's blazingly faster in this case), and working folders are smaller (which still blows my mind).

嗯，它是分布式的。基准测试表明它要快得多（鉴于其分布式特性，差异和日志等操作都是本地的，所以在这种情况下当然要快得多），并且工作文件夹更小（这仍然让我大吃一惊）。

When you're working on subversion, or any other client/server revision control system, you essentially create working copies on your machine by checking-outrevisions. This represents a snapshot in time of what the repository looks like. You update your working copy via updates, and you update the repository via commits.

当您使用 subversion 或任何其他客户端/服务器版本控制系统时，您实际上是通过检出修订在您的机器上创建工作副本。这表示存储库外观的时间快照。您通过更新更新您的工作副本，并通过提交更新存储库。

With a distributed version control, you don't have a snapshot, but rather the entire codebase. Wanna do a diff with a 3 month old version? No problem, the 3 month old version is still on your computer. This doesn't only mean things are way faster, but if you're disconnected from your central server, you can still do many of the operations you're used to. In other words, you don't just have a snapshot of a given revision, but the entire codebase.

使用分布式版本控制，您没有快照，而是整个代码库。想用 3 个月大的版本做一个差异吗？没问题，3 个月前的版本仍在您的计算机上。这不仅意味着事情变得更快，而且如果您与中央服务器断开连接，您仍然可以执行许多您习惯的操作。换句话说，您不仅拥有给定修订版的快照，还拥有整个代码库的快照。

You'd think that Git would take up a bunch of space on your harddrive, but from a couple benchmarks I've seen, it actually takes less. Don't ask me how. I mean, it was built by Linus, he knows a thing or two about filesystems I guess.

你会认为 Git 会占用你硬盘上的大量空间，但从我看到的几个基准测试来看，它实际上占用的空间更少。不要问我如何。我的意思是，它是由 Linus 构建的，我猜他对文件系统了解一两件事。

回答by Emmanuel Caradec

The main points I like about DVCS are those :

我喜欢 DVCS 的要点是：

1. You can commit broken things. It doesn't matter because other peoples won't see them until you publish. Publish time is different of commit time.
2. Because of this you can commit more often.
3. You can merge complete functionnality. This functionnality will have its own branch. All commits of this branch will be related to this functionnality. You can do it with a CVCS however with DVCS its the default.
4. You can search your history (find when a function changed )
5. You can undo a pull if someone screw up the main repository, you don't need to fix the errors. Just clear the merge.
6. When you need a source control in any directory do : git init . and you can commit, undoing changes, etc...
7. It's fast (even on Windows )

1. 你可以犯下坏事。没关系，因为其他人在您发布之前不会看到它们。发布时间与提交时间不同。
2. 因此，您可以更频繁地提交。
3. 您可以合并完整的功能。此功能将有自己的分支。此分支的所有提交都将与此功能相关。您可以使用 CVCS 执行此操作，但默认使用 DVCS。
4. 您可以搜索您的历史记录（查找功能何时更改）
5. 如果有人搞砸了主存储库，您可以撤消拉取，您不需要修复错误。只需清除合并。
6. 当您需要在任何目录中进行源代码管理时，请执行： git init 。并且您可以提交、撤消更改等...
7. 它很快（即使在 Windows 上）

The main reason for a relatively big project is the improved communication created by the point 3. Others are nice bonuses.

一个相对较大的项目的主要原因是第 3 点创造的改进的沟通。其他都是不错的奖励。

回答by Andre Bossard

The funny thing is: I host projects in Subversion Repos, but access them via the Git Clone command.

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

Please read Develop with Git on a Google Code Project

请阅读在 Google 代码项目上使用 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.

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

Using Git on a Svn Repository gives me benefits:

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

1. I can work distributedon several machines, commiting and pulling from and to them
2. I have a centralbackup/publicsvn repository for others to check out
3. And they are free to use Git for their own

1. 我可以在多台机器上分布式工作，向它们提交和拉取
2. 我有一个中央backup/publicsvn 存储库供其他人查看
3. 他们可以自由地使用 Git

回答by si618

All the answers here are as expected, programmer centric, however what happens if your company uses revision control outside of source code? There are plenty of documents which aren't source code which benefit from version control, and should live close to code and not in another CMS. Most programmers don't work in isolation - we work for companies as part of a team.

这里的所有答案都符合预期，以程序员为中心，但是如果您的公司在源代码之外使用修订控制会怎样？有很多文档不是从版本控制中受益的源代码，并且应该靠近代码而不是在另一个 CMS 中。大多数程序员并不是孤立地工作——我们作为团队的一部分为公司工作。

With that in mind, compare ease of use, in both client tooling and training, between Subversion and git. I can't see a scenario where anydistributed revision control system is going to be easier to use or explain to a non-programmer. I'd love to be proven wrong, because then I'd be able to evaluate git and actually have a hope of it being accepted by people who need version control who aren't programmers.

考虑到这一点，比较 Subversion 和 git 在客户端工具和培训中的易用性。我看不到任何分布式版本控制系统将更易于使用或向非程序员解释的场景。我很乐意被证明是错误的，因为那样我就可以评估 git 并且实际上希望它被需要版本控制的人而不是程序员所接受。

Even then, if asked by management why we should move from a centralised to distributed revision control system, I'd be hard pressed to give an honest answer, because we don't need it.

即便如此，如果管理层问我们为什么要从集中式修订控制系统转向分布式修订控制系统，我也很难给出诚实的答案，因为我们不需要它。

Disclaimer: I became interested in Subversion early on (around v0.29) so obviously I'm biased, but the companies I've worked for since that time are benefiting from my enthusiasm because I've encouraged and supported its use. I suspect this is how it happens with most software companies. With so many programmers jumping on the git bandwagon, I wonder how many companies are going to miss out on the benefits of using version control outside of source code? Even if you have separate systems for different teams, you're missing out on some of the benefits, such as (unified) issue tracking integration, whilst increasing maintenance, hardware and training requirements.

免责声明：我很早就对 Subversion 感兴趣（大约 v0.29），所以显然我有偏见，但从那时起我工作的公司都从我的热情中受益，因为我一直鼓励和支持它的使用。我怀疑这就是大多数软件公司的情况。有这么多程序员加入 git 潮流，我想知道有多少公司会错过在源代码之外使用版本控制的好处？即使您为不同的团队使用单独的系统，您也会错过一些好处，例如（统一的）问题跟踪集成，同时增加了维护、硬件和培训要求。

回答by neu242

Subversion is still a much more used version control system, which means that it has better tool support. You'll find mature SVN plugins for almost any IDE, and there are good explorer extensions available (like TurtoiseSVN). Other than that, I'll have to agree with Michael: Git isn't better or worse than Subversion, it's different.

Subversion 仍然是一个使用较多的版本控制系统，这意味着它有更好的工具支持。您会发现几乎所有IDE 的成熟 SVN 插件，并且有很好的资源管理器扩展可用（如 TurtoiseSVN）。除此之外，我不得不同意Michael 的观点：Git 并不比 Subversion 更好或更差，它是不同的。