目前，想从 Subversion 过渡到 Git 其实并不困难，只要你不把 Git 和 Subversion混淆就行。一旦你明白了两者在概念上的区别，这个改变的过程就会变得容易。
分布式与集中式
Subversion是一个集中式（centralized）的版本控制系统。所有的开发团队成员都工作在单一的远程中央仓库上，当在这个中央仓库上进行 “签出（checkout）” 操作时，它就会在你的本地计算机上设置一个 “工作副本（working copy）”。这就是一个存储在你本地计算机上的一个特定版本的快照。
Git从 Subversion过渡到GitGit是一个分部式（distributed）的版本控制系统，它有着一个不同的工作方式。相对于Subversion 的 “签出（checkout）”，每一个Git用户会从远程仓库“克隆（clone）”出一个本地仓库。反过来说，一个用户会得到一个完整的仓库，而不仅仅只是一个工作副本。用户在本地计算机上拥有自己的仓库，并且包含所有的项目历史记录。用户可以在自己的本地计算机上做任何想要操作，例如提交（commit），历史检查（inspect history），恢复到一个旧的版本等等。只有当你想要共享你的工作结果时，你才需要连接到远程服务器上。
仓库结构和 URLs
一个 Subversion 的仓库通常都是由几个目录组织起来的。“trunk” 目录对应你的开发主线，“branches” 目录对应那些特定的工作背景下的开发，而 “tags” 目录则用来标记一个特定的版本。它们都要通过自己的 URL 来指向到它在中央仓库中的具体位置：
svn+ssh://svn@example.com/svn/trunkGit
仓库就完全不一样了，它的组成完全就是一个在项目根目录下的 “.git” 文件夹。对分支和标记的查找完全依靠命令，而不是通过 URLs。Git 的 URL 只指向仓库的位置。
ssh://git@example.com/path/to/git-repo.git
分支
正如刚才提到的， Subversion 的分支仅仅是一些有特殊含义的目录。在创建一个新的分支时，你只是把项目的当前状态完完整整地拷贝到这个新的分支目录中。
Git 的分支技术是它的设计核心，因此它拥有一个完全不同的概念。一个在 Git 中的分支就是一个指向一个特定版本的指针：不拷贝任何文件；不创建任何目录；没有任何额外的操作。在 Git 中你永远工作在一个分支上，至少工作在那个系统默认创建的 “master” 分支上。在你的工作副本上只包括你当前的活动分支中的文件（ Git 称之为 “HEAD”）。所有其他的版本和分支都被保存在你的本地仓库中，并且随时都可以非常快速地恢复到一个旧的版本。一定要记住 Git 的分布式特性：分支可以被发布到在远程服务器上，但是本地上的分支对于日常的工作更加重要。
提交
-
当你想要在 Subversion 中提交一个改动，有如下的一些规则：
-
你必须确保与中央仓库的连接。你不能进行离线提交。
-
提交的内容要立即存储在中央仓库中。
-
它会被分配一个递增版本号。
提交在 Git 中就是完全另外一种情况：
-
你没有必要连接到任何一个 “中央” 仓库，因为在你的计算机中就拥有一个完整的本地仓库。因此提交仅仅只记录在本地仓库上。它们不会自动地传递到远程仓库中，除非你自己决定共享这个改动。
-
文件的改动并不意味着它会被自动地包含在下一次提交中。你必须指明哪些改动你想要提交，并把它添加的所谓的 “暂存区（Staging Area）”中。你甚至可以只对文件的部分修改或是特定的几行代码进行提交，而其他部分则稍后提交。
-
“commit hashes” 替代了版本号码。由于提交都发生在开发人员的本地计算机上，你不可能给某个提交分配一个号码 #5，而另外一个分配 #6，这就产生了个问题，在分布式系统下谁是第一个提交呢？在 Git 中，每一个提交必须拥有一个唯一的ID，因此一个哈希字符串就代替了那个依次递增的版本号。
分享工作
在 Subversion 中，在提交之后，你的工作会被自动地转移到中央仓库上去。只有在你连接到这个中央服务器时你才可以进行提交。
不会自动上传任何东西。你可以自己决定，你的那些分支（也可能是所有分支）需要共享给你其他的团队成员。除此之外共享工作也是十分安全的。冲突只会出现在你的本地上，它决不可能发生在远程服务器上。这会让你有信心来解决冲突，因为你不会破坏远程仓库。
为什么选择 Git
虽然市场上有几十种不同的版本控制系统，一些世界上最著名的项目（例如 Linux 内核，Ruby on Rails，或是jQuery）都选择了使用 Git 作为它们的版本控制系统。为什么它们都选择 Git 呢？
节省时间Git
运行快速。尽管我们在这里讨论的只是运行一个命令所需要的几秒钟，但是把它累积在你的日常工作中就是一个不小的飞跃了。它可以节省那些不必要的等待时间，并且去完成其它一些有意义的工作。
离线工作
当你不能联机远程中央仓库时你该怎么工作呢？对于一个像 Subversion 或者 CVS 的集中式版本控制系统来说，如果你没有连接到中央仓库，你就不能很好的工作。如果使用 Git ，几乎所有的东西都可以简单地在你的本地机器上完成。例如进行提交，查看你的项目历史，合并或者创建分支等等。至于在哪里工作？什么时候工作？ Git 不会给你施加任何限制。
撤销错误操作
每个人都会犯错，而使用 Git 的最大好处就在于，几乎在所有的情况下你都能 “撤消” 你的错误操作。比如如果你忘记了把一个小小的改动包含进来，因此你要改正你的上个提交。又或者你想要撤销一个完整的提交，因为这个功能有可能是不必要的。当发生了很严重的错误时，你甚至可以通过恢复引用日志来让一个提交不可见。你可以放心，Git 几乎很少真正地删除数据。
可靠性高
不用担忧，你不会在 Git 中搞砸任何东西，这种感觉是不是非常好？在你的 Git 项目中的每一个团队成员都克隆了整个项目在他们的本地计算机，这个本地克隆也可以看作一个完整的项目备份。除此之外， Git 上的操作几乎都是进行数据添加，几乎从不删除数据。这意味着丢失数据或是仓库损坏的情况几乎不可能发生。
让提交更有意义
只有包含了相关的改动的提交才有意义。想象一下，如果一个提交中包括一个新添加的功能 A，还包括功能 B 的一部分改动，并且还存在一个对错误 C 的修复。这样其他的团队成员就很难理解这个提交的意图，而且当其中的一个改动出现了错误，撤销起来也非常麻烦。利用它独一无二的 “暂存区（staging area）” 概念，Git 可以帮助你打造很细微和精准的提交。你可以准确地判断哪些更改将被包含在你的下一个提交中，即使只是一行改动。Git 真正提高了对版本控制的实用性。
更高的自由度
当使用 Git 工作时，你可以定义一个对项目和团队有意义的工作流程。使用 Git 也不需要其它的要求。你可以连接多个远程仓库，使用 rebase 来替代合并，或者在需要时可以使用子模块。当然，你也可以简单地像 Subversion 那样仅仅使用一个远程的集中式仓库。无论你使用什么样的工作流程，它都有各种各样的优点。
避免混乱
关注点分离可以更明确地了解事情的进程。当你工作在功能 A 上时，不应该有任何人受到你未完成的代码的影响。如果那个功能是完全没有必要的话呢？或是完成了对它的一些改动提交后，你注意到你完全错了呢？分支功能就可以解决这些问题。当然其他版本控制系统也都有分支，但是 Git 真正的把它改进地更快速，更简单了。
顺应潮流
聪明的开发人员应该顺应潮流。Git 正在被越来越多的知名公司和开源项目所使用，如 RubyOn Rails，jQuery，Perl，Debian，Linux 内核等等。拥有一个大型的用户群体是一个很大优势，因为往往会存在很多系统去推动他的发展。大量的教程，工具和服务，这让Git更加具有吸引力。
本文由 小马哥 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为:
2017/11/23 09:24
