现在用svn的多还是git的多（git和svn哪个好）

本文目录

• git和svn哪个好
• Git和SVN的区别，哪个好
• 企业使用svn和git哪个多一些
• Git和SVN，代码管理哪个更好

git和svn哪个好

GIT是分布式的，SVN不是：这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提 交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。GitHub.com就是一个这样的优秀案例。有些谣言传出来说subversion将来的版本也会基于分布式模式。但至少目前还看不出来。GIT把内容按元数据方式存储，而SVN是按文件：所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它 们差距很大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。GIT分支和SVN的分支不同：分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。感谢Ben同学指出这个特征。所以，经常会发生有些分支被遗漏的情况。然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。GIT没有一个全局的版本号，而SVN有：目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道，SVN的版本号实际是任何一个相应时间的源代码快照。我认为它是从CVS进化到 SVN的最大的一个突破。因为GIT和SVN从概念上就不同，我不知道GIT里是什么特征与之对应。如果你有任何的线索，请在评论里奉献出来与大家共享。更新：有些读者指出，我们可以使用GIT的SHA-1来唯一的标识一个代码快照。这个并不能完全的代替SVN里容易阅读的数字版本号。但，用途应该是相同的。GIT的内容完整性要优于SVN：GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。这里有一个很好的关于GIT内容完整性的讨论 –

Git和SVN的区别，哪个好

1) 最核心的区别Git是分布式的，而Svn不是分布的。能理解这点，上手会很容易，声明一点Git并不是目前唯一的分布式版本控制系统，还有比如Mercurial等，所以说它们差不许多。话说回来Git跟Svn一样有自己的集中式版本库和Server端，但Git更倾向于分布式开发，因为每一个开发人员的电脑上都有一个Local Repository,所以即使没有网络也一样可以Commit，查看历史版本记录，创建项 目分支等操作，等网络再次连接上Push到Server端。从上面看GIt真的很棒，但是GIt adds Complexity,刚开始使用会有些疑惑，因为需要建两个Repositories(Local Repositories & Remote Repositories),指令很多，除此之外你需要知道哪些指令在Local Repository，哪些指令在Remote Repository。 2)Git把内容按元数据方式存储，而SVN是按文件：因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。.git目录的体积大小跟.svn比较，你会发现它们差距很大。 3) Git没有一个全局版本号，而SVN有：目前为止这是跟SVN相比Git缺少的最大的一个特征。 4) Git的内容的完整性要优于SVN: GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。 5) Git下载下来后，在OffLine状态下可以看到所有的Log,SVN不可以。 6) 刚开始用时很狗血的一点，SVN必须先Update才能Commit,忘记了合并时就会出现一些错误，git还是比较少的出现这种情况。 7) 克隆一份全新的目录以同样拥有五个分支来说，SVN是同时复制5个版本的文件,也就是说重复五次同样的动作。而Git只是获取文件的每个版本的 元素，然后只载入主要的分支(master)在我的经验,克隆一个拥有将近一万个提交(commit),五个分支,每个分支有大约1500个文件的 SVN,耗了将近一个小时！而Git只用了区区的1分钟！ 8) 版本库（repository):SVN只能有一个指定中央版本库。当这个中央版本库有问题时，所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。而 Git可以有无限个版本库。或者，更正确的说法，每一个Git都是一个版本库，区别是它们是否拥有活跃目录（Git Working Tree）。如果主要版本库（例如：置於GitHub的版本库）发生了什麼事，工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库！ 9)分支（Branch）在SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开启新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来进行破坏工作（安检测试），那将会像传染病一样,你改一个分支，还得让其他人重新切分支重新下载，十分狗血。而 Git，每个工作成员可以任意在自己的本地版本库开启无限个分支。举例：当我想尝试破坏自己的程序（安检测试），并且想保留这些被修改的文件供日后使用， 我可以开一个分支，做我喜欢的事。完全不需担心妨碍其他工作成员。只要我不合并及提交到主要版本库，没有一个工作成员会被影响。等到我不需要这个分支时， 我只要把它从我的本地版本库删除即可。无痛无痒。 Git的分支名是可以使用不同名字的。例如：我的本地分支名为OK，而在主要版本库的名字其实是master。 最值得一提，我可以在Git的任意一个提交点（commit point）开启分支！（其中一个方法是使用gitk –all 可观察整个提交记录，然后在任意点开启分支。） 10)提交（Commit）在SVN，当你提交你的完成品时，它将直接记录到中央版本库。当你发现你的完成品存在严重问题时，你已经无法阻止事情的发生了。如果网路中断，你根本没办法提交！而Git的提交完全属於本地版本库的活动。而你只需“推”（git push）到主要版本库即可。Git的“推”其实是在执行“同步”（Sync）。最后总结一下：SVN的特点是简单，只是需要一个放代码的地方时用是OK的。Git的特点版本控制可以不依赖网络做任何事情，对分支和合并有更好的支持(当然这是开发者最关心的地方)，不过想各位能更好使用它，需要花点时间尝试下。

企业使用svn和git哪个多一些

企业使用git多一些，原因如下：

• 因为git版本库占用空间小；

• git是分布式管理系统，完全可以不对代码进行备份；

• git不用时时联网查询；

• 如果客户端离服务器端非常远，在网速糟糕的情况下，用svn下载代码速度远不上git。

1. git版本库占用空间小，SVN每个分支都是一份代码的copy，而git每个分支只是各个提交点的hash值的集合。分支几乎不占用什么空间。

2. git是分布式管理系统，完全可以不对代码进行备份，但SVN不行，一旦服务器的硬盘挂掉整个代码库就完了。

3. git不用时时联网查询，并且对文件进行压缩，使得文件体积大大减小，并且传输速度快，svn是单个文件，git是压缩后的，在使用svn时我已经碰到过好几次服务器无响应了。由于git很多都可以在本地操作的，所以大大降低了客户端对服务器的连接，出现这种情况的概率会大大减小。

参考资料

git官网.git官网

Git和SVN，代码管理哪个更好

代码版本管理系统的历史

代码版本管理系统大致可以分为三个时代：

第一代：本地式

这代主要的特点提供本地代码版本控制，比如SCCS(1972)、 PVCS(1985)等。

这代主要实现了基本的代码版本管理，但缺点是无法让多人同时对一个版本库进行修改。这个也和当时软件规模不够大有关，也没有这样的需求。

第二代：客户端-服务器式

这代主要的特点是提供集中式服务器端代码版本控制,比如 CVS(1986), ClearCase(1992), Visual SourceSafe(1994), Perforce(1995), Subversion(2000) 等。

这代主要是实现了中心服务器端的代码版本管理，特点是可以让多人同时对一个代码版本库进行同步和修改，但缺点也相当明显：

• 在无法连接服务器的情况下，无法查看日志以及提交和比较代码版本（慢速网络和远程异地工作的程序员的痛），以及当服务或者网络出现问题的时候很多人员就会无法工作。

• 不支持local branch，导致branch创建管理复杂，并且一旦创建就很难修改（快速迭代开发中的程序员的痛）

• 由于只有一个中心端服务器，一旦发生灾难性问题，那么所有日志都会丢失，所以需要经常做备份（备份需要不小的成本）

• 如果软件代码量过于庞大，一般会出现速度缓慢的情况，因为每次的日志查询、不同版本之间的代码比较和代码提交等操作都需要和服务器通信，造成服务器端的负载过大。

第三代：分布式

这代主要的特点是提供分布式代码版本控制,比如Git(2005), Mercurial(2005)等。

这代结合了第一代和第二代的优点并实现了分布式的代码版本管理。

这代的优点：分布式管理，在没有和服务器有连接的情况下仍然可以查看日志，提交代码，创建分支；支持local branch，可以快速方便的实现各种分支管理；支持分布式，从而可以实现分块管理，以及负载分流管理。

缺点是有一定的学习曲线，比如分布方式下的代码同步，local branch的理解与运用，分布式代码管理的理解与运用等。详细的比较可以参考：这里。

二、大型分布式团队

曾经有这样一个分布式团队，他们在多个城市都有小分队，并且正在开发一个大型项目，见下图

他们使用的代码版本管理工具是第二代代码管理工具SVN，管理方案如下：

但是他们在使用的过程中却遇到了下面这些问题与痛点。

由于是分布式团队，所以：

• 基于团队的代码模块分离困难

当服务器不可用时：

• 不能查看提交记录

• 不能比较文件

• 不能提交代码

创建代码分支时：

• 分支创建速度慢

• 多分支管理困难

在提交代码时：

• 希望有Code Review

• 希望有CI Review

因为代码庞大：

• 查看日志慢

备份代码库的时候：

• 需要停机备份

• 备份成本高

针对以上问题，可以使用新一代的分布式的代码版本管理系统来解决，见下图：

其中每一个团队都有自己独立的代码库，有一个中心库用于同步这些独立的代码库，并且每个库都由团队自己管理和维护。而且代码版本管理系统需要支持轻量分支，代码评审，离线提交，离线查看日志等功能。

但是由于当前没有一个单一的代码版本管理工具能同时满足以上所有需求，所以很多公司都基于它们开发集成管理系统，比如Gerrit，GitLab，GitHub，BitBucket等。其中的Gerrit由于其开源，免费，以及由Google开发和维护，并管理着Android，OpenStack等大型项目源代码的特点，成为了大型分布式团队优先选择的系统。

三、Gerrit

Gerrit是由Google开发的，用于管理Google Android项目源代码的一个系统。它是基于Java和Prolog等开发的，支持Git，权限管理，代码评审等综合的一个管理系统。它与GitLab和GitHub最大的不同是它隐藏了代码分库管理的细节，使得开发人员不需要进行fork这样的手工分库和同步操作就可以进行代码开发和提交，节省了开发人员的时间,见下图。

由于Android本身是一个开源项目，所以贡献者非常多，开发团队也遍布多个地方（存在时差），导致“如何保证代码质量”成为一个很大的问题。为此Google在Gerrit中加入了功能强大并且十分严格的代码评审系统。

首先当代码提交以后并不会直接merge到中心库里面，它会暂时存在一个临时库里面，同时生成一个代码评审记录，并向特定的评审人员发送请求评审的邮件。当评审者在评审代码之后，如果通过就需要在Gerrit系统里面对代码进行打分，如果通过了就可以将代码merge到中心库里面去，如果没有通过，那么这个代码提交就需要被返还给开发者进行修改。

与此同时它还可以自动触发一次包含本次代码提交的CI构建（前提需要手工预先配置），如果CI自动构建和测试通过，也可以自动在Gerrit系统里面进行打分，可以给最终进行merge的人员进行参考。示意流程见下图。

由于Android源代码由上百个独立的代码库组成，并且编译一个Android系统需要大部分代码库里面的代码，所以如何管理如此多的代码库也是一个难题，比如如何一次性同步需要编译一个需要支持特定设备的代码库组合。为此Google基于Python语言开发一个工具叫Repo ，这个工具可以自定义你需要的代码库的组合，并且一次性对这些代码库进行同步，比如pull和push，见下图。

四、SVN到Git的迁移

对于想从集中式代码管理系统迁移到分布式代码管理系统的团队来讲，如果团队规模小，那么问题一般都不大，但是对于大型分布式团队却是困难重重。最主要的两个困难：

• 代码量太大，很难一次性将所有的代码和日志等在短时间内迁移成功。

• 由于下属团队太多，很难同一时间让所有团队都切换至新的代码管理工具。

为了解决这些难题，一般都会首先选用1个团队来使用新的代码版本管理工具。如果这个团队转换成功，再将其作为标杆向其他团队推广，从而逐步的将所有团队切换到新的工具上去。

SVN到Git的迁移方案一般主要会使用两种工具：

• 开源免费的git-svn；

• 商业收费的Subgit。

其中使用Subgit的迁移方案如下图：

如果团队组资源充足，还可以使用Gerrit搭建一个独立的Git服务器，从而以分布式的方式进行代码迁移，如下图：

五、多产品线的管理

使用同一个中心代码库管理多产品线一直是大型项目的一个困难点，特别是使用SVN这样的工具更是难以管理，因为SVN这种工具的Branch本质上是一个目录拷贝，并且速度慢，而且代码回迁也需要手动进行。但是如果使用Git的特性来管理多产品线，比起SVN是事半功倍。具体方案见下图：

总结：

分布式代码版本管理系统并不一定适合所有团队，比如中小团队可能更关心的只是成本更低，简单易用，那么SVN等这类集中式版本管理工具还是更为适合。但是不管团队最终选用什么代码版本管理工具，只要适合自己的团队的开发流程和工作方式，并且代码管理顺畅就可以了。