Question

众所周知，git在这些日子里非常受欢迎，因为它具有高效率，因为它具有本地计算机上的所有历史记录，并且可以在没有网络的情况下完成历史检索。也许对于外联网用户来说，网络问题并不重要，但是git也有其他类型的优势，比如轻量级分支（我还不确定它和svn的分支之间有什么区别，为什么git的分支很轻）？

我也知道很多人还在使用颠覆，为什么？如果git很好，他们可能会切换到git：）

那么，这里有人可以告诉我颠覆的一些优点吗？

还有一个问题：

is there anything which can be done by svn, but cannot be done with git?

Answer 1

我建议你阅读这篇文章 "10 things I hate about Git"和StackOverflow线程SVN vs Git。我还建议你阅读this doc about Subversion and Git。

虽然其他人已经提到简单（简单是Apache Subversion的商标;） BTW）和清晰的工作流程作为Subversion的主要优势我想添加一些其他重要的Apache Subversion 专业人员：

更好的IDE集成和GUI。 您可以在大多数IDE中看到内置的SVN客户端（或作为插件实现）。其中一些提供了与IDE非常舒适和直观的版本控制集成。另一方面，除了众所周知的GitHub之外，Git没有良好的图形界面。 IDE集成仍在进行中，但Git的hacky命令行性质并没有真正转化为GUI。你仍然必须使用命令行来处理比分支或拉/推更复杂的事情。

BTW，TortoiseSVN Subversion客户端可被视为适用于Windows的最佳版本控制客户端。
Subversion是集中。换句话说，distributed systems are NOT so-called "next generation VCS"（你好，Eric Sink等人），他们是，嗯，刚刚分发。分布式只是另一种非常适合开源项目的方法，例如Linux Kernel（Git是为Linux Kernel开发的，还记得吗？）但它有其自身的缺点。
完整修订历史记录。 SVN维护目录，重命名和文件元数据的版本控制。 Subversion就像一个具有不可变历史的时间机器。您可以随时使用机器返回，以检查日期的样子，例如2009年1月3日。
部分结帐。使用Subversion，您无需获得完整的存储库克隆。您可以签出项目的特定分支或主干。更重要的是，您可以获取存储库的任何子树。极大地减少了开始处理任务所需的流量。如果您已有工作副本，则切换到另一个分支或搁置 instant （如果您有远程仓库的连接，显然）。
Locking support。 Subversion支持lock-modify-unlock versioning model。 Git没有。如果您有不可合并的文件，这可能非常有用。你好gamedev！：）
内置authorization和authentication机制。

Answer 2

简单。

诸如“什么是遥控器？”，“为什么要修改消息？”，“这个改变什么东西？”之类的问题。有必要了解Git提供的所有功能，你需要了解它们才能真正了解为什么Git如此棒。

但是对于一个设计师或任何从Git开始的技术人员来说，这真的很令人头痛。 Subversion是众所周知的，它的集中化方式使所有这些人都能理解它。

使用Subversion可以更快地开始工作和制作东西（假设你已经设置了环境;）。）

Answer 3

Git是关于拥有个人权力，而Svn是关于企业权力（作为一个宏大的主张）。

Git知道不再需要保护Master文档免受伤害。相反，现在有许多副本，除非经过sha1验证，否则更难以管理。

Svn知道人们是愚蠢的（但不是你和我;-)并且认为知道谁重命名并移动了重要内容，并且该内容可以在以后签署。

Git让你用剪刀，玩杂耍链锯和制作你的产品。 Svn提供防护服，工作指示和一种安全措施。

这是关于选择你想要钉在地板上的脚; - ）

Answer 4

Git分支是“轻量级的”，因为它们只是指针：git只是在特定的提交中指向'master'或'development'或'trunk'或'myfeature'。当你重新提交分支时，指针前进。请考虑此git-scm docs,关于该主题的恒星资源的图表。

git branch pointers

此图表中的“主”分支指向提交f30ab。 'testing'分支指向提交c2b9e。此图中的HEAD是一个特殊指针：大多数时候它指向另一个分支（在git术语中，它是一个“符号引用”）来显示工作目录的当前检出状态。当您发出git checkout f30ab时，您将存储库置于“分离的HEAD”状态。换句话说，您将指针从符号引用“测试”移动到提交f30ab。

举一个例子，你应该可以在本地设置一个。

git init /tmp/test && cd /tmp/test          ;# make a repo and cd to it
echo A > A                                  ;# add a file
git add A && git commit -m "first commit"   ;# make the first commit
echo B > B                                  ;# add another file
git add B && git commit -m "second commit"  ;# commit that one too
git checkout -b development                 ;# now let's checkout development
echo C > C                                  ;# commit one more file
git add C && git commit -m "third commit"   ;# and commit that final one

你现在有了类似下面的内容。我没有omnigraffle所以我们坚持使用有向图：

  * 93e71ee - (HEAD, development) third commit
 /  
* 6378754 - (master) second commit
* d2b4ba9 - first commit

正如您可以从括号中推断出，'master'指向提交6378754，'development'指向提交93e71ee，HEAD指向'开发'。不要相信我的话。自己探索指针：

$ cat .git/refs/heads/master              ;# cat the 'master' pointer
5a744a27e01ae9cddad02531c1005df8244d188b
$ cat .git/refs/heads/development         ;# now cat the 'development' one
93e71ee0a538b0e8ac548e3936f696fa4936f8dc
$ cat .git/HEAD                           ;# note that 'HEAD' points at 'development'
ref: refs/heads/development
$ git symbolic-ref HEAD                   ;# as we can also show with 'symbolic-ref'
refs/heads/development

当分支只是指针时，在它们之间切换是微不足道的。一个特例是HEAD。考虑一下我们结账大师时会发生什么：

$ git checkout master    ;# checkout master...
$ cat .git/HEAD          ;# where are we now?
ref: refs/heads/master

签出提交怎么样？

$ git checkout d2b4ba9                  ;# this will throw some advice
Note: checking out 'd2b4ba9'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

$ cat .git/HEAD                         ;# 'HEAD' points at a commit
d2b4ba97698d7f528f9ba1e08d978a70651b3b1d
$ git symbolic-ref HEAD                 ;# and thus isn't a symbolic reference
fatal: ref HEAD is not a symbolic ref

这个建议是什么意思？在“分离的HEAD”状态下提交存储库会生成从任何分支无法访问的提交。当HEAD更改（来自任何结帐操作，例如git checkout master）时，这些提交将会丢失。这在图表中更容易看到：

echo D > D                                  ;# add another file
git add D && git commit -m "fourth commit"  ;# and commit it

让我们看看我们的图表。注意没有git命令会生成你在下面看到的内容。为了这个例子的目的，我修改了现有的输出。

      * 93e71ee - (development) third commit
     /
    * 6378754 - (master) second commit
   /
* / 72c1f03 - (HEAD) fourth commit
|/
* d2b4ba9 - first commit

HEAD仍然是分离的。它指向72c1f03。 'master'和'development'指向我们所期望的位置，但72c1f03无法从任何分支到达。那是个问题。如果我想保留72c1f03，我必须给它一个分支：

$ git checkout -b experimental    ;# checkout 'experimental' based on '72c1f03'
$ cat .git/HEAD                   ;# HEAD is once again pointed at a branch
ref: refs/heads/experimental
$ git symbolic-ref HEAD           ;# and is a symbolic ref
refs/heads/experimental

图表：

      * 93e71ee - (development) third commit
     /
    * 6378754 - (master) second commit
   /
* / 72c1f03 - (HEAD, experimental) fourth commit
|/
* d2b4ba9 - first commit

Git使分支变得容易。推送和拉出有关指针的信息比推送和拉动整组文件要快得多。切割分支需要几毫秒。这很容易，几乎感觉不对。因此，git允许更多distributed workflow options,，尽管它也可以处理集中式的。{/ p>

Answer 5

从SVN切换到git是一项艰巨的任务（我们已经在公司工作了6个月），因为它需要在公司中进行大量更改（培训，服务器，与问题跟踪等其他工具的通信）。。，安全）。

我能找到的唯一优势就是它的简单性（因为你不能做比git更多的事情），工作流程更容易理解和应用，所以如果你害怕不是所有同事都能/想要处理git的复杂性或者不需要它的功能，然后保持svn。

看看this SO thread说服自己：）。

与git相比，颠覆的优势是什么？

5 个答案: