我并没有真正回答你的问题，但如果你想要分布式版本控制的好处——听起来是这样的——并且你正在使用Windows，我认为你最好使用Mercurial而不是Git，因为Mercurial对Windows的支持要好得多。Mercurial也有Mac移植版本。

我可以扩展一下这个问题，并问Git在MacOS上是否运行良好吗?

回复评论:谢谢你告诉我这个消息，我一直期待着尝试一下。我会把它安装在家里的Mac电脑上。

我并没有真正回答你的问题，但如果你想要分布式版本控制的好处——听起来是这样的——并且你正在使用Windows，我认为你最好使用Mercurial而不是Git，因为Mercurial对Windows的支持要好得多。Mercurial也有Mac移植版本。

这是我在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，因为Windows充其量是git世界中的二等公民(更多细节请参阅http://en.wikipedia.org/wiki/Git_(software)#Portability)。

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

在做了更多的研究，并查看了这个链接: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。

我很想听听其他人在读完上面的文章后会怎么说?