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

(摘录如下):

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.

在阅读了所有这些之后，我确信Git是可行的方法(尽管存在一点学习曲线)。我也在Windows平台上使用过Git和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，因为我觉得它比SVN强大得多。有一些便宜的代码托管服务对我来说非常有用——你不需要做备份或任何维护工作——GitHub是最明显的候选者。

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

这是我在2009年9月删除Git vs. SVN的问题后，对一些重复问题的回答的副本。

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

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

第一部分产生了一些错误的评论，假装这两个程序(SVN和Git)的基本目的是相同的，但它们的实现却截然不同。 为了澄清SVN和Git之间的根本区别，让我重新表述一下:

SVN is the third implementation of a revision control: RCS, then CVS and finally SVN manage 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.

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

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的团队能够相当成功地抛弃SVN，转而使用Git的原因。 如果他们不解决同一个问题，这种可替代性就不会存在。

，我回答说:

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

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

你当然不能(总是)用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.

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

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

这可以归结为:

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

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

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

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