3

众所周知，现在git非常流行，因为它的历史记录都在本地计算机上，效率很高，而且可以在没有网络的情况下检索历史记录。也许对于外网用户来说，网络问题并不那么重要，但git还有其他优点，例如轻量级分支（我仍然不确定它和svn的分支有什么区别，为什么git的分支是轻量级的）？

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

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

还有一个问题：

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

5 回答 5

12

我建议您阅读文章 “我讨厌 Git 的 10 件事”和 StackOverflow 线程SVN vs Git。我还建议阅读有关 Subversion 和 Git 的文档。

虽然其他人已经提到简单（简单是 Apache Subversion 的商标；）顺便说一句）和清晰的工作流程是 Subversion 的主要优势，但我想添加一些其他重要的 Apache Subversion优点：

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

    顺便说一句，TortoiseSVN Subversion 客户端可以被认为是适用于 Windows 的最佳版本控制客户端。

  • 颠覆是中心化的。换句话说，分布式系统不是所谓的“下一代 VCS”（你好，Eric Sink 等人！），嗯，它们只是分布式的。分布式只是另一种方法，它非常适合 Linux Kernel 等开源项目（Git 是为 Linux Kernel 开发的，记得吗？），但也有其自身的缺点。

  • 完整的修订历史。SVN 维护目录、重命名和文件元数据的版本控制。Subversion 就像一台具有不可变历史的时间机器。您可以随时使用机器回到过去，查看您的日期在 2009 年 1 月 3 日时的样子。

  • 部分结账。使用 Subversion，您无需获得完整的存储库克隆。您可以签出项目的特定分支或主干。更重要的是，您可以获得存储库的任何子树。大大减少开始执行任务所需的流量。如果你已经有一个工作副本，切换到另一个分支或搁置是即时的（如果你有连接到远程仓库，显然）。

  • 锁定支持。Subversion 支持lock-modify-unlock 版本控制模型。吉特没有。如果您有不可合并的文件，这将非常有用。你好游戏开发！:)

  • 内置授权和身份验证机制。

于 2012-08-28T10:39:32.473 回答
6

简单。

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

但对于一个设计师或任何从 Git 开始的技术人员来说，这真的只是一个令人头疼的问题。Subversion 是众所周知的，它的集中方式让所有这些人都更容易理解它。

您可以使用 Subversion 更快地开始工作和生产东西（前提是您已经设置了环境；））。

于 2012-08-28T09:14:57.957 回答
5

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

Git 知道不再有必须保护免受伤害的主文档。而是现在有许多副本，除非经过 sha1 验证，否则更难以管理。

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

Git 让您可以用剪刀跑步、玩弄链锯并制作您的产品。Svn 提供防护服、工作说明和一种安全措施。

这是关于选择你想把哪只脚钉在地板上;-)

于 2012-08-28T11:39:49.290 回答
3

Git 分支是“轻量级”的，因为它们只是指针：git 只是在特定提交处指向“master”或“development”或“trunk”或“myfeature”。当您在分支上重新提交时，指针会前进。考虑git-scm 文档中的这张图表，这是关于该主题的一流资源。

git 分支指针

此图中的“master”分支指向 commit f30ab。'testing' 分支指向 commit c2b9e。HEAD在这个图中是一个特殊的指针：大多数时候它指向另一个分支（在 git 术语中，它是一个“符号引用”）以显示当前工作目录的签出状态。例如，当您发出 时git checkout f30ab，您将存储库置于“分离的 HEAD”状态。换句话说，您将指针从符号引用“testing”移动到提交，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”指向 commit 6378754，“development”指向 commit 93e71ee，HEAD指向“development”。不要相信我的话。自己探索指针：

$ 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。考虑当我们 checkout master 时会发生什么：

$ 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 允许更多分布式工作流选项，尽管它当然也可以处理集中式工作流选项。

于 2012-08-28T13:51:12.287 回答
2

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

我能找到的唯一优点是它的简单性（因为你不能做的事情比在 git 中做的多），工作流更容易理解和应用，所以如果你害怕不是所有同事都可以/想要处理 git 的复杂性或不需要它的特性，然后继续使用svn。

看看这个 SO 线程来说服自己:)。

于 2012-08-28T09:14:29.893 回答