GIT和SVN之间的五个基本区别

如果你在读这篇文章,说明你跟大多数开发者一样对GIT感兴趣,如果你还没有机会来试一试GIT,我想现在你就要了解它了。

GIT不仅仅是个版本控制系统,它也是个内容管理系统(CMS),工作管理系统等。如果你是一个具有使用SVN背景的人,你需要做一定的思想转换,来适应GIT提供的一些概念和特征。所以,这篇文章的主要目的就是通过介绍GIT能做什么、它和SVN在深层次上究竟有什么不同来帮助你认识它。

那好,这就开始吧…

  1. GIT是分布式的,SVN不是:

    这是GIT和其它非分布式的版本控制系统,例如SVN,CVS等,最核心的区别。如果你能理解这个概念,那么你就已经上手一半了。需要做一点声明,GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统,例如Bitkeeper, Mercurial等,也是运行在分布式模式上的。但GIT在这方面做的更好,而且有更多强大的功能特征。

    GIT跟SVN一样有自己的集中式版本库或服务器。但,GIT更倾向于被使用于分布式模式,也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说,如果你被困在一个不能连接网络的地方时,就像在飞机上,地下室,电梯里等,你仍然能够提交文件,查看历史版本记录,创建项目分支,等。对一些人来说,这好像没多大用处,但当你突然遇到没有网络的环境时,这个将解决你的大麻烦。

    同样,这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐,你不必再像以前那样做出补丁包,通过email方式发送出去,你只需要创建一个分支,向项目团队发送一个推请求。这能让你的代码保持最新,而且不会在传输过程中丢失。GitHub.com就是一个这样的优秀案例。

    有些谣言传出来说subversion将来的版本也会基于分布式模式。但至少目前还看不出来。

  2. GIT把内容按元数据方式存储,而SVN是按文件:

    所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较,你会发现它们差距很大。因为,.git目录是处于你的机器上的一个克隆版的版本库,它拥有中心版本库上所有的东西,例如标签,分支,版本记录等。

  3. GIT分支和SVN的分支不同:

    分支在SVN中一点不特别,就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支,你需要手工运行像这样的命令svn propget svn:mergeinfo,来确认代码是否被合并。感谢Ben同学指出这个特征。所以,经常会发生有些分支被遗漏的情况。

    然而,处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支,你能简单而快捷的合并这些文件。

  4. GIT没有一个全局的版本号,而SVN有:

    目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道,SVN的版本号实际是任何一个相应时间的源代码快照。我认为它是从CVS进化到SVN的最大的一个突破。因为GIT和SVN从概念上就不同,我不知道GIT里是什么特征与之对应。如果你有任何的线索,请在评论里奉献出来与大家共享。

    更新:有些读者指出,我们可以使用GIT的SHA-1来唯一的标识一个代码快照。这个并不能完全的代替SVN里容易阅读的数字版本号。但,用途应该是相同的。

  5. GIT的内容完整性要优于SVN:

    GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性,确保在遇到磁盘故障和网络问题时降低对版本库的破坏。这里有一个很好的关于GIT内容完整性的讨论 – http://stackoverflow.com/questions/964331/git-file-integrity

GIT和SVN之间只有这五处不同吗?当然不是。我想这5个只是“最基本的”“最吸引人”的,我只想到这5点。如果你发现有比这5点更有趣的,请共享出来,欢迎。

分享这篇文章:
[英文原文:5 Fundamental differences between GIT & SVN ]

38 Responses to GIT和SVN之间的五个基本区别

  1. 依云 says:

    连 stash 和 暂存区 都没有提到。。。。

  2. ganggang says:

    好,不错

  3. ganggang says:

    还可以,感觉稍微却一点

  4. Frank says:

    学习了,一开始我以为git与svn差不多,了解了之后觉得还是差别挺大的,在设计理念上有很大的差别。在过几年会不会出现一个比git还要强大的东西?

  5. Yong says:

    我们公司用的SVN,不过我想了解一下Git,看了你的文章收益良多了,呵呵

  6. yy says:

    svn每次版本提交记录的都是修改部分
    git记录的是完整的

  7. XX says:

    GIT可以非常方便的对以前的提交内容进行修改,比如,本地提交之后发现,某地方的标点符号忘记了……然后选择“修改上次提交”即可。而svn……

    其实我感觉那啥版本标识没啥用,看一看日志就够了,反正git中的那一堆hash可以非常方便的复制出来的。

  8. Fox says:

    我还是找不到去用git的理由,用git真的有必要么?是为了显得自己很高端的样子么?

    • Dennis Y.S. says:

      我是一開始就用Mercurial, Git這類的系統。(現在已經百分百用Git了。)
      用過Git之後才接觸SVN,發現了一些非常大的差別。在這裡提出我個人一些主要理由為何棄SVN而用Git。

      1。速度:
      克隆一份全新的目錄,以同樣擁有五個(才五個)分支來說,SVN是同時複製5個版本的文件,也就是說重複五次同樣的動作。而Git只是獲取文件的每個版本的元素,然後只載入主要的分支(master)。在我的經驗,克隆一個擁有將近一萬個提交(commit),五個分支,每個分支有大約1500個文件的SVN,耗了將近一個小時!而Git只用了區區的1分鐘!

      2。版本庫(repository):
      據我所知,SVN只能有一個指定中央版本庫。當這個中央版本庫有問題時,所有工作成員都一起癱瘓直到版本庫維修完畢或者新的版本庫設立完成。

      而Git可以有無限個版本庫。或者,更正確的說法,每一個Git都是一個版本庫,區別是它們是否擁有活躍目錄(Git Working Tree)。如果主要版本庫(例如:置於GitHub的版本庫)發生了什麼事,工作成員仍然可以在自己的本地版本庫(local repository)提交,等待主要版本庫恢復即可。工作成員也可以提交到其他的版本庫!

      3。分支(Branch)
      在SVN,分支是一個完整的目錄。且這個目錄擁有完整的實際文件。如果工作成員想要開啟新的分支,那將會影響“全世界”!每個人都會擁有和你一樣的分支。如果你的分支是用來進行破壞工作(安檢測試),那將會像傳染病一樣。

      而Git,每個工作成員可以任意在自己的本地版本庫開啟無限個分支。舉例:當我想嘗試破壞自己的程序(安檢測試),並且想保留這些被修改的文件供日後使用,我可以開一個分支,做我喜歡的事。完全不需擔心妨礙其他工作成員。只要我不合并及提交到主要版本庫,沒有一個工作成員會被影響。等到我不需要這個分支時,我只要把它從我的本地版本庫刪除即可。無痛無癢。
      Git的分支名是可以使用不同名字的。例如:我的本地分支名為testing,而在主要版本庫的名字其實是master。
      最值得一提,我可以在Git的任意一個提交點(commit point)開啟分支!(其中一個方法是使用gitk –all 可觀察整個提交記錄,然後在任意點開啟分支。)

      4。提交(Commit)
      在SVN,當你提交你的完成品時,它將直接記錄到中央版本庫。當你發現你的完成品存在嚴重問題時,你已經無法阻止事情的發生了。如果網路中斷,你根本沒辦法提交!

      而Git的提交完全屬於本地版本庫的活動。而你只需“推”(git push)到主要版本庫即可。Git的“推”其實是在執行“同步”(Sync)。

      5。重新設立起點(Rebase)
      我沒在SVN嘗試過,不知道有沒有這樣的功能。

      在Git,如果你想把別人的最新提交設立為現在這個分支的起點,只要執行git rebase branch_name 即可。這個和合并(merge)不同點是,merge會依據修改的時間視為最新,而Rebase會要求你去解決雙方都有修改過的地方的矛盾(conflict)。

      A - B - E
      \- C - D
      A - B - E
      \ - C - D

      6。系統檔案
      SVN會在每一個目錄置放一個.svn。如果想移除這些.svn是很累的。
      而Git會在目錄起點擁有一個.git目錄,以及.gitignore。

      對我而言,管理一個Git 的版本庫是很容易的事。

  9. 阿蒙 says:

    离线提交,足矣!!!

  10. Mongo says:

    额 还没用过 git

  11. 非洲驴 says:

    学会怎么用git以后再来评论,只用过win下的svn。

  12. Yonghang Jiang says:

    打算去用github了。

  13. zhenyu 对这篇文章的反应是赞一个
  14. 屈飞驰 对这篇文章的反应是赞一个
  15. 曹先生 对这篇文章的反应是赞一个
  16. Ken says:

    最不理解的也被你们不断吹嘘的用处:Git在网络中断的情况下提交有什么实际用处?其它人还是获取不了你的最新代码啊-我们提交代码是为了别人能工作的最新的代码,而不是为了你保存方便!换句话说:每人提交代码前起码要先更新最新的代码到本地,并且本地编译成功;更好一点要测试一下,以免影响别人的工作。

    • 山里来的鱼 says:

      离线干活,又恰巧有需求回滚的时候,你就会发现Git的好处了,当然,不只是回滚这个功能,commit也是,离线干活的时候,很可能要commit多次的,当然还有更多的离线需求。另外,如何私有?如果有些东西只想自己用,但是又不想Ctrl+C,Ctrl+V的时候,咋办,找管理员申请?Git能帮助你,当然,很可能n天之后,你又想将你的代码公开……还有服务器宕机,项目组所有成员都可以基于本地的版本库恢复。

  17. For_Iris 对这篇文章的反应是赞一个
  18. 张媛· 对这篇文章的反应是赞一个
  19. selam says:

    用过svn,个人认为公司内部研发使用svn的还是比较多

  20. 方海亮 对这篇文章的反应是垃圾
  21. sunsam 对这篇文章的反应是垃圾
  22. 看看 says:

    细节的地方讲得不清不楚,很容易让新手产生混乱。

  23. Ivan says:

    在使用SVN的时候有时候会遇到这种情况:刚做了个小需求,还没完全验证完,所以就没提交到SVN,但是突然又来了个小需求,做了一段时间发现居然这个需求被取消了(或者移到另一个工程里面开发)!这个时候,就得把工程里面后面的这个需求涉及的内容回滚掉。但是这两个小需求都在同一个工程里面,涉及很多个文件修改。这个时候,想在SVN本地是没法回滚的,因为两个需求都没提交过。
    我想使用GIT以后,这种情况应该很容易就处理了吧?可以先把第一个需求的实现提交本地,后面第二个需求取消,就可以直接在本地回滚了吧。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

壹加壹等于