我已经使用SVN很长时间了，但是每当我使用Git时，我都觉得Git非常强大，轻量级，尽管有一点学习曲线，但它比SVN要好。

我所注意到的是，每个SVN项目，随着它的发展，都会变成一个非常大的项目，除非它被导出。其中，GIT项目(以及GIT数据)的大小非常轻。

在SVN中，我与从新手到专家的开发人员都打过交道，如果新手和中级开发人员为了重用一个文件夹而从另一个SVN项目复制文件夹，他们似乎会引入文件冲突。然而，我认为在Git中，你只需要复制文件夹就可以了，因为Git没有在所有子文件夹中引入. Git文件夹(就像SVN那样)。

在很长一段时间内处理了大量的SVN之后，我终于考虑将我和我的开发人员转移到Git，因为它很容易协作和合并工作，还有一个很大的优势是，本地副本的更改可以根据需要提交，然后最终推送到服务器上的分支，而不像SVN(我们必须不时地在服务器上的存储库中提交更改)。

谁能帮我决定我是否真的应该使用Git?

Git在Windows下还不受本地支持。它针对Posix系统进行了优化。然而，运行Cygwin或MinGW可以让你成功运行Git。

现在我更喜欢Git而不是SVN，但是如果你来自CVS, SVN的土地，它需要一段时间才能超过阈值。

我从来没有理解过“git在Windows上不好”这个概念;我只在Windows下开发，git从来没有遇到过任何问题。

我绝对推荐git而不是subversion;它只是更加通用，并且允许“离线开发”，这是subversion永远无法做到的。它可以在几乎所有可以想象到的平台上使用，并且拥有比你可能使用过的更多的功能。

肯定是svn，因为Windows充其量是git世界中的二等公民(更多细节请参阅http://en.wikipedia.org/wiki/Git_(software)#Portability)。

更新:抱歉断开的链接，但我已经放弃尝试让SO与包含括号的uri一起工作。[链接现在固定。——编者)

这是我在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中注册!)

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

我会选择SVN，因为它传播更广泛，知名度更高。

我想Git更适合Linux用户。