我应该使用 SVN 还是 Git？

Should I use SVN or Git?

提问by rudigrobler

I am starting a new distributed project. Should I use SVN or Git, and why?

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

回答by Oli

SVN is one repo and lots of clients. Git is a repo with lots of client repos, each with a user. It's decentralised to a point where people can track their own edits locally without having to push things to an external server.

SVN 是一个 repo 和许多客户。Git 是一个拥有许多客户端存储库的存储库，每个存储库都有一个用户。它是分散的，人们可以在本地跟踪自己的编辑，而无需将内容推送到外部服务器。

SVN is designed to be more central where Git is based on each user having their own Git repo and those repos push changes back up into a central one. For that reason, Git gives individuals better local version control.

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

Meanwhile you have the choice between TortoiseGit, GitExtensions(and if you host your "central" git-repository on github, their own client – GitHub for Windows).

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

If you're looking on getting out of SVN, you might want to evaluate Bazaarfor a bit. It's one of the next generation of version control systems that have this distributed element. It isn't POSIX dependant like git so there are native Windows buildsand it has some powerful open source brands backing it.

如果您正在考虑退出 SVN，您可能需要稍微评估一下Bazaar。它是具有这种分布式元素的下一代版本控制系统之一。它不像 git 那样依赖 POSIX，所以有原生的 Windows 构建，并且它有一些强大的开源品牌支持它。

But you might not even need these sorts of features yet. Have a look at the features, advantages and disadvantages of the distributed VCSes. If you need more than SVN offers, consider one. If you don't, you might want to stick with SVN's (currently) superior desktop integration.

但是您甚至可能还不需要这些类型的功能。查看分布式 VCS 的特性、优点和缺点。如果您需要的不仅仅是 SVN 产品，请考虑一个。如果不这样做，您可能希望坚持使用 SVN（当前）卓越的桌面集成。

回答by Dark Shikari

I have never understand this concept of "git not being good on Windows"; I develop exclusively under Windows and I have never had any problems with git.

我一直不明白“git 在 Windows 上不好用”的概念；我专门在 Windows 下开发，我从来没有遇到过 git 问题。

I would definitely recommend git over subversion; its simply so much more versatile and allows "offline development" in a way subversion never really could. Its available on almost every platform imaginable and has more features than you'll probably ever use.

我肯定会推荐 git 而不是 subversion；它只是更加通用，并且允许以颠覆从未真正做到的方式进行“离线开发”。它几乎可以在所有可以想象的平台上使用，并且具有比您可能使用过的更多功能。

回答by VonC

Here is a copy of an answer I made of some duplicate question since then deletedabout Git vs. SVN (September 2009).

这是我对一些重复问题的回答的副本，此后删除了有关 Git 与 SVN（2009 年 9 月）的问题。

Better? Aside from the usual link WhyGitIsBetterThanX, they are different:

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

one is a Central VCS based on cheap copy for branches and tags the other (Git) is a distributed VCS based on a graph of revisions. See also Core concepts of VCS.

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

---

---

That first part generated some mis-informed comments pretending that the fundamental purpose of the two programs (SVN and Git) is the same, but that they have been implemented quite differently.
To clarify the fundamental difference between SVN and Git, let me rephrase:

第一部分产生了一些错误的评论，假装这两个程序（SVN 和 Git）的基本目的是相同的，但它们的实现方式却大不相同。
为了澄清SVN 和 Git 之间的根本区别，让我改写一下：

• SVN is the third implementation of a revisioncontrol: RCS, then CVS and finally SVNmanage directories of versioned data. SVN offers VCS features (labeling and merging), but its tag is just a directory copy (like a branch, except you are not "supposed" to touch anything in a tag directory), and its merge is still complicated, currently based on meta-data added to remember what has already been merged.

• Git is a file content management(a tool made to merge files), evolved into a true Version Control System, based on a DAG (Directed Acyclic Graph) of commits, where branches are part of the history of datas (and not a data itself), and where tags are a true meta-data.

• SVN 是版本控制的第三个实现：RCS，然后是 CVS，最后是 SVN管理版本化数据的目录。SVN 提供了 VCS 的特性（标记和合并），但是它的标签只是一个目录副本（就像一个分支，除了你“不应该”接触标签目录中的任何东西），它的合并仍然很复杂，目前基于元- 添加数据以记住已合并的内容。

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

To say they are not "fundamentally" different because you can achieve the same thing, resolve the same problem, is... plain false on so many levels.

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

• if you have many complex merges, doing them with SVN will be longer and more error prone. if you have to create many branches, you will need to manage them and merge them, again much more easily with Git than with SVN, especially if a high number of files are involved (the speed then becomes important)
• if you have partial merges for a work in progress, you will take advantage of the Git staging area (index) to commit only what you need, stash the rest, and move on on another branch.
• if you need offline development... well with Git you are always "online", with your own local repository, whatever the workflow you want to follow with other repositories.

• 如果你有很多复杂的合并，用 SVN 做它们会更长，更容易出错。如果您必须创建许多分支，则需要管理它们并合并它们，使用 Git 比使用 SVN 更容易，尤其是在涉及大量文件时（速度变得很重要）
• 如果您对正在进行的工作进行了部分合并，您将利用 Git 暂存区（索引）仅提交您需要的内容，存储其余部分，然后在另一个分支上继续前进。
• 如果您需要离线开发……使用 Git，您始终“在线”，拥有自己的本地存储库，无论您想在其他存储库中遵循什么工作流程。

---

---

Still the comments on that old (deleted) answer insisted:

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

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 substitutabilitywouldn't exist.

VonC：您混淆了实施上的根本区别（差异非常重要，我们都清楚地同意这一点）与目的不同。
它们都是用于相同目的的工具：这就是为什么许多以前使用过 SVN 的团队能够非常成功地将其转储到 Git 中的原因。
如果他们不解决同样的问题，这种可替代性就不存在了。

, to which I replied:

，对此我的回答是：

"substitutability"... interesting term (used in computer programming).
Off course, Git is hardly a subtype of SVN.

“替代性”...有趣的术语（用于计算机编程）。
当然，Git 几乎不是 SVN 的子类型。

You may achieve the same technical features (tag, branch, merge) with both, but Git does not get in your way and allow you to focus on the content of the files, without thinking about the tool itself.

您可以使用两者实现相同的技术特性（标记、分支、合并），但 Git 不会妨碍您并让您专注于文件的内容，而无需考虑工具本身。

You certainly cannot (always) just replace SVN by Git "without altering any of the desirable properties of that program (correctness, task performed, ...)" (which is a reference to the aforementioned substitutability definition):

你当然不能（总是）只用 Git 替换 SVN，“而不改变该程序的任何理想属性（正确性，执行的任务，......）”（这是对上述替代性定义的引用）：

• One is an extended revision tool, the other a true version control system.
• One is suited small to medium monolithic project with simple merge workflow and (not too much) parallel versions. SVN is enough for that purpose, and you may not need all the Git features.
• The other allows for medium to large projects based on multiple components (one repo per component), with large number of files to merges between multiple branches in a complex merge workflow, parallel versions in branches, retrofit merges, and so on. You could do it with SVN, but you are much better off with Git.
  SVN simply can not manage any project of any size with any merge workflow. Git can.

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

Again, their nature is fundamentally different(which then leads to different implementation but that is not the point).
One see revision control as directories and files, the other only see the content of the file (so much so that empty directories won't even register in Git!).

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

The general end-goal might be the same, but you cannot use them in the same way, nor can you solve the same class of problem (in scope or complexity).

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

回答by user154489

2 key advantages of SVN that are rarely cited:

很少被引用的 SVN 的 2 个关键优势：

1. Large file support. In addition to code, I use SVN to manage my home directory. SVN is the only VCS (distributed or not) that doesn't choke on my TrueCrypt files (please correct me if there's another VCS that handles 500MB+ files effectively). This is because diff comparisons are streamed (this is a very essential point). Rsync is unacceptable because it's not 2-way.

2. Partial repository (subdir) checkout/checkin. Mercurial and bzr don't support this, and git's support is limited. This is bad in a team environment, but invaluable if I want to check something out on another computer from my home dir.

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

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

Just my experiences.

只是我的经历。

回答by Waqar

After doing more research, and reviewing this link: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

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

(Some extracts below):

（部分摘录如下）：

• It's incredibly fast. No other SCM that I have used has been able to keep up with it, and I've used a lot, including Subversion, Perforce, darcs, BitKeeper, ClearCase and CVS.
• It's fully distributed. The repository owner can't dictate how I work. I can create branches and commit changes while disconnected on my laptop, then later synchronize that with any number of other repositories.
• Synchronization can occur over many media. An SSH channel, over HTTP via WebDAV, by FTP, or by sending emails holding patches to be applied by the recipient of the message. A central repository isn't necessary, but can be used.
• Branches are even cheaper than they are in Subversion. Creating a branch is as simple as writing a 41 byte file to disk. Deleting a branch is as simple as deleting that file.
• Unlike Subversion branches carry along their complete history. without having to perform a strange copy and walk through the copy. When using Subversion I always found it awkward to look at the history of a file on branch that occurred before the branch was created. from #git: spearce: I don't understand one thing about SVN in the page. I made a branch i SVN and browsing the history showed the whole history a file in the branch
• Branch merging is simpler and more automatic in Git. In Subversion you need to remember what was the last revision you merged from so you can generate the correct merge command. Git does this automatically, and always does it right. Which means there's less chance of making a mistake when merging two branches together.
• Branch merges are recorded as part of the proper history of the repository. If I merge two branches together, or if I merge a branch back into the trunk it came from, that merge operation is recorded as part of the repostory history as having been performed by me, and when. It's hard to dispute who performed the merge when it's right there in the log.
• Creating a repository is a trivial operation: mkdir foo; cd foo; git init That's it. Which means I create a Git repository for everything these days. I tend to use one repository per class. Most of those repositories are under 1 MB in disk as they only store lecture notes, homework assignments, and my LaTeX answers.
• The repository's internal file formats are incredible simple. This means repair is very easy to do, but even better because it's so simple its very hard to get corrupted. I don't think anyone has ever had a Git repository get corrupted. I've seen Subversion with fsfs corrupt itself. And I've seen Berkley DB corrupt itself too many times to trust my code to the bdb backend of Subversion.
• Git's file format is very good at compressing data, despite it's a very simple format. The Mozilla project's CVS repository is about 3 GB; it's about 12 GB in Subversion's fsfs format. In Git it's around 300 MB.

• 它非常快。我使用过的其他 SCM 都无法跟上它的步伐，而且我使用了很多，包括 Subversion、Perforce、darcs、BitKeeper、ClearCase 和 CVS。
• 它是完全分布式的。存储库所有者无法决定我的工作方式。我可以在我的笔记本电脑上断开连接时创建分支并提交更改，然后将其与任意数量的其他存储库同步。
• 同步可以发生在许多媒体上。SSH 通道，通过 WebDAV 通过 HTTP、通过 FTP，或通过发送包含要由消息接收者应用的补丁的电子邮件。中央存储库不是必需的，但可以使用。
• 分支甚至比在 Subversion 中更便宜。创建分支就像将 41 字节文件写入磁盘一样简单。删除一个分支就像删除那个文件一样简单。
• 与 Subversion 分支不同的是，它们会保留完整的历史记录。无需执行奇怪的副本并遍历副本。在使用 Subversion 时，我总是觉得查看分支上的文件在分支创建之前发生的历史记录很尴尬。来自 #git: spearce: 我不明白页面中关于 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。

After reading all this, I'm convinced that Git is the way to go (although a little bit of learning curve exists). I have used Git and SVN on Windows platforms as well.

阅读完所有这些后，我确信 Git 是必经之路（尽管存在一些学习曲线）。我也在 Windows 平台上使用过 Git 和 SVN。

I'd love to hear what others have to say after reading the above?

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

回答by Greg Hewgill

I would set up a Subversion repository. By doing it this way, individual developers can choose whether to use Subversion clients or Git clients (with git-svn). Using git-svndoesn't give you allthe benefits of a full Git solution, but it does give individual developers a great deal of control over their own workflow.

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

I believe it will be a relatively short time before Git works just as well on Windows as it does on Unix and Mac OS X (since you asked).

我相信 Git 在 Windows 上的运行效果与在 Unix 和 Mac OS X 上的运行效果一样好还需要相对较短的时间（因为你问过）。

Subversion has excellent tools for Windows, such as TortoiseSVN for Explorer integration and AnkhSVN for Visual Studio integration.

Subversion 具有适用于 Windows 的出色工具，例如用于资源管理器集成的 TortoiseSVN 和用于 Visual Studio 集成的 AnkhSVN。

回答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 ayaz

If your team is already familiar with version and source control softwares like cvs or svn, then, for a simple and small project (such as you claim it is), I would recommend you stick to SVN. I am really comfortable with svn, but for the current e-commerce project I am doing on django, I decided to work on git (I am using git in svn-mode, that is, with a centralised repo that I push to and pull from in order to collaborate with at least one other developer). The other developer is comfortable with SVN, and while others' experiences may differ, both of us are having a really bad time embracing git for this small project. (We are both hardcore Linux users, if it matters at all.)

如果您的团队已经熟悉 cvs 或 svn 等版本和源代码控制软件，那么对于简单且小型的项目（如您声称的那样），我建议您坚持使用 SVN。我对 svn 真的很满意，但是对于我在 django 上做的当前电子商务项目，我决定使用 git（我在 svn 模式下使用 git，也就是说，使用我推送和拉取的集中式存储库以便与至少一位其他开发人员合作）。另一位开发人员对 SVN 很满意，虽然其他人的经验可能有所不同，但我们俩都在为这个小项目接受 git 的过程中度过了一段非常糟糕的时光。（如果这很重要的话，我们都是 Linux 的铁杆用户。）

Your mileage may vary, of course.

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

回答by Dave Webb

Not really answering your question but if you want the benefits of Distributed Revision Control- it sounds like you do - and you're using Windows I think you'd be better off using Mercurialrather that Git as Mercurial has much better Windows support. Mercurial does have a Mac port too.

不是真的回答你的问题，但如果你想要分布式修订控制的好处- 听起来你喜欢 - 并且你使用的是 Windows 我认为你最好使用Mercurial而不是 Git 作为 Mercurial 有更好的 Windows 支持。Mercurial 也有 Mac 端口。

回答by Mnementh

The main point is, that Git is a distributed VCS and Subversion a centralized one. Distributed VCSs are a little bit more difficult to understand, but have many advantages. If you don't need this advantages, Subversion may the better choice.

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

Another question is tool-support. Which VCS is better supported by the tools you plan to use?

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

EDIT:Three years ago I answered this way:

编辑：三年前我是这样回答的：

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 目前只能通过 Cygwin 或MSYS在 Windows 上运行。Subversion 从一开始就支持 Windows。由于适用于 Windows 的 git-solutions 可能适合您，因此可能存在问题，因为大多数 Git 开发人员使用 Linux 并且从一开始就没有考虑可移植性。目前我更喜欢在 Windows 下开发 Subversion。几年后，这可能无关紧要。

Now the world has changed a little bit. Git has a good implementation on windows now. Although I tested not thouroughly on windows (as I no longer use this system), I'm quite confident, that all the major VCS (SVN, Git, Mercurial, Bazaar) have proper Windows-implementation now. This advantage for SVN is gone. The other points (Centralized vs. Distributed and the check for tool support) stay valid.

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