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

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

你必须使用DVCS，它就像源代码管理的一个量子飞跃。就我个人而言，我使用Monotone和它加速的开发时间没有结束。我们在Windows、Linux和Mac上使用它，它非常稳定。我甚至让buildbot在每个平台上进行每晚的项目构建。

分布式DVCS通常意味着您将创建一个中央服务器，仅供人们推送更改。

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

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

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

请阅读在谷歌代码项目中使用Git进行开发

虽然谷歌代码原生说话 Subversion，可以轻松使用Git 在开发过程中。搜索“git” Svn建议这种做法是正确的 广泛传播，我们也鼓励你 用它来做实验。

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

我可以分配到几个 机器，承诺和从 对他们来说 我有一个中央备份/公共svn存储库供其他人检查 他们可以自由地使用Git

你试过Bzr吗?

这很好，cononical(制作Ubuntu的人)制作它是因为他们不喜欢市场上的其他东西……

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

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