【码农】Git相对于SVN的优势是什么？
- storespace0930前提：请教各位大神，我司纯内网开发，目前采用svn进行管理，还没有启用分支功能。有三套服务器，开发，测试，生产。没分支，因此部署生产环境比较麻烦，经常需要手动做临时文件。因此打算研究一下版本管理的分支。说到版本管理，那必须研究Git，都说git的分支很厉害。昨天花了半天看了一下，本地、远端、工作区、提交区各种概念。理清楚了也还算可以，但是对团队来说，学习曲线还是陡了，因为团队里还有一些老同志。
网络上看衰SVN的主要观点就是svn的分支开销很大，速度很慢，合并很慢，需要手动解决很多冲突。
于是我做了实验，把我们最大的一个项目，大约2.2GB，做了一个分支。秒完成，检查服务器代码库，数据并没有翻倍，还是那么大。
切换到分支，做了一通修改，提交到服务器后。又切回主干，合并分支的修改，还是秒完成，并没有传说中的慢。
不知道有没有同时精通SVN和Git的大神，教教我这二者的实际区别是什么。我实验下来，觉得svn的分支还是很堪用的，学习成本又低，团队使用很合适啊 - lifanxigit提供了去中心化的分布式设计，而SVN无法脱机使用。
对于Linux内核这样的项目，git是明显优于SVN的。企业场景下SVN确实也可能够用，但是git跟SVN比，几乎没有任何劣势，所以现在推崇git比较多。 - 李大饼git上传做了压缩，上传很快；做分支更方便。
- 无风而动SVN 最大的问题不是多人协同么？
同一个文件无法多个人同时更改，必须一个人更改完了，团队所有人拉取最新文件，然后更改同个文件。如果刚好两个人都改了同个文件，就要解决冲突。GIT 基本上没有这个问题，除非两个人改的是同一个文件的同一行内容。
照顾老同志的话，用图形化工具就行了
https://desktop.github.com
其实这个标题应该是：SVN 相对于GIT有什么优势？ - znm你们这场景 iOS fly ~
- s229959178我这边还在用perforce iOS fly ~
- jehh楼主svn服务端用的哪种？
- 4color常规用用都可以。主要现在git用的人多。而且用的都是云管理。
- copyleft2000除非为了目录级别的权限控制，否则我觉得一般场景下git是完胜svn的。最主要的，git现在太主流了啊，git工具多，我们自己搭了gitlab，用它自家的ci做持续集成，嗷嗷好用
- zj9819看代码量吧，之前公司SVN合代码很头疼。
如果只是分支问题的话，可以制定一些适合的工作流，SVN或者Git问题都不大。 - happy1993Git挺好入手的吧，我大概一周多就基本可以上手了，配合bitbucket和jira很好用，我现在用的repo大概5个g iOS fly ~
- ablemanci/cd支持的更好 iOS fly ~
- xtyzh用过git以后就再也回不去了，轻巧，几条命令本地就可以开搞。功能也够强大。代码量大svn基本没办法玩。
- flowerszhong还有一个原因，正是git的优势，导致git服务生态都很强，越来越强三胖网
- 莲尖去中心化 iOS fly ~
- hoopzhou我之前用的是perfoce，和git比最大的差距我感觉是在离线下的情况。
比如网络断了，用perfoce的话，本地就没有任何版本管理能力。
git不存在这个问题。 - storespace0930回复3#李大饼
忘记说了，纯内网开发环境，网速很快。
回复4#无风而动
svn可以多人修改同一个文件，如果文件行没冲突，它也会自动合并，这个和git没什么区别。git学习有难度，当然也不是不能克服，但是如果没有压倒性的优势，强迫团队切换git也不是很合适。
回复5#znm
这场景在企业信息系统开发很常见啊，有什么问题吗？
回复7#jehh
用的是visual svn server，非常易用稳定，好多年了，管了200多G的代码，没出过幺蛾子。性能也没问题。
回复10#zj9819
你们合并代码出现的问题主要是什么，用git后改善了吗？核心差异是什么呢？
回复12#ableman
ci我理解，是check in，cd是啥？ - hoopzhouCI是持续集成，CD是持续交付
Continue Integraion 和 Delivery - x8blaze大工程git比SVN速度快很多，我们现在一个ATV差不多80G，使用SVN checkout的时间简直难以接受，当然google本身使用repo也不方便我们转为SVN。习惯了git也很方便，不过git有个问题就是不能把修改提交到标签，这对版本小修改不太友好
- fortyminsCI是continuous integration CD是continuous deliver
- storespace0930
- storespace0930
- xtyzh
- networm_cn学习一下
- Ricepiggit两个主要优势是速度快和分布式吧
说细节的话还有本地版本HiPDA·嗯唧 - MiniStar不想理解具体技术的话，就是速度快，效率高。 iOS fly ~
- swsh007对啊
git是有学习曲线的
其次关键是针对于核心项目来讲够不够用
这个跟cmm，iso这种是一个道理，
广义上讲，git适合异地分布式开发。 - 51vip
- 碧的绿用过git就不会再用svn了。灵活运用分支太方便了，本地可以随便玩，玩好了再推到服务器
- inevity这个年代还用svn？ 可以无脑用那git了。
- 木鱼虫感觉git用得很痛苦
- znm话说了一半，我觉得这场景你们感觉不到太大区别，svn commit 代码一步，git 2步，另外git和各种开发ide集成非常好用
- peng123456刚把svn 服务器换了git 速度快了很多。
- CrossAge用gitflow啊，大小feature，版本补丁hotfix团队协同开发起来井井有条，目前找不到替代。svn啊，回不去了。
- Haisea单纯分支，两者区别不大
git主要是去中心化，不需要连服务器，本地就可以进行版本管理，commit是提交到本地，要保存到服务器，是push
以你们的使用情况（分支都没用），替换成git应该也是很容易的，常用的几条命令学下就好了 - storespace0930回复23#xtyzh
我觉得还好，初次checkout大约要十来分钟，但是这个我觉得git 初次clone下来也差不多，毕竟一大堆小文件。后续开发什么的都很快了，一次十来个文件，没什么问题，写完提交说明，按提交，一两秒也就结束了。diff是指比较单个文件的差异吗？那这个git应该会快很多，毕竟有本地库，svn要花个一两秒。
回复25#Ricepig
速度快和分布式对内网开发意义不大，本地版本确实挺爽。
回复30#inevity
git确实火了很多年了，但是对于我们内网开发来说，好像真没发现有什么优势。相反，svn上手太简单了，一分钟就讲完了，基本没培训成本。
回复32#znm
目前同事用eclipse和idea的都有（我们主要是java和网页开发）svn插件，用起来也挺方便。不知道git插件有什么优点。今天我大约用了一下，感觉分支可视化方面git好很多。
回复33#peng123456
我们在内网，svn平常也没感觉慢。不知道你们git比svn快，是2秒对20秒，还是1秒对5秒，如果是后者，其实svn也能接受。
回复34#CrossAge
大小feature，版本补丁hotfix按我理解，就是分支和tag标签，是这样的吗？gitflow是一个软件，还是一套规范？我一会学习一下。
回复35#Haisea
哎，一言难尽。我昨天花了一个小时看了git的教程，确实觉得上手不算难。但是团队三四十号人，有老有少，还有外包，还有写方案的，各种角色。让他们都用好，实在没把握，因此不到万不得已，不想换。目前看起来，svn分支还是堪用的，性能和易用上似乎没什么问题。网络上很多文章误导性太强。 - xfygx楼主，继续用 SVN 好了。当年，大家都说 C 不行了。结果十多年下来，C 地位还是第一。
GIT 也是不错的，但如果 SVN 用的好好的，而且，根据你说的情况，完全没必要换到 GIT 上。 - storespace0930https://cloud.tencent.com/developer/ask/27238
zt一个资料
抛开个人立场，理性评估利弊，可能才是我认可的一个资深程序员，或者一个架构师的本分。
我所在的团队，现在选用的技术方案是git作为全公司的版本控制系统，我们一共有差不多20个程序员，使用五种以上的程序设计语言，研发维护四个左右的项目，属于小型创业公司中，研发规模中等偏上的企业。使用git作为版本控制系统，在我加入公司之前，已经是既成事实了，在我听说这一点的时候，我非常高兴，因为我说过，我喜欢git。
上周五，我们公司新来的工程师，在周会上分享git，有个同事挑战道，为什么git比svn更好？这个问题，如果是问我个人的话，我可能会有很多的理由，但是，就像我一贯的思维模式，说服别人的时候，必须给出足够令人信服的原因，不能使用主观因素去说服别人，那样只能引起争论。
对于，“为什么git比svn更好”这个问题，我真的很想给出一个肯定的答案，但是，我在探寻答案的过程中，遇到了困难。于是，我来尝试一下站在反面的立场来给出一份答卷，然后，我们再反过来辩论，于是就有了本文的题目。
SVN到底有什么优点
广泛的群众基础。从我开始使用版本控制系统，我用的就已经是SVN了，所以，想要追溯SVN到底从什么时候开始，不得不求助于维基百科，我发现，SVN首个正式版本，可以追溯到2000年，距今已经十五年历史了。在github成为大热门之前，SVN基本处于一统天下的地位。几乎所有的公司都在使用SVN作为内部的版本控制系统，Google Code更是掀起了开源软件的浪潮，一时间，几乎全世界的程序员，都在使用SVN。
我敢说，我们公司目前招聘的程序员，还没有没用过SVN的。这意味着，如果公司使用SVN的话，他们快速上手的概率，是非常高的。现在中国中小企业和创业企业，程序员招聘的困难程度，我不想多阐述——谁负责，谁头疼——如果使用SVN的话，学习版本控制系统用法这种事情，不会成为你脑海里的一个问题。
优异的跨平台支持 。年龄大这种事情，并非总是缺点，在跨平台支持这个角度，就会成为优势。十五年来，SVN几乎积累了所有平台上优秀的客户端软件。Windows平台的TortoiseSVN的成功，简直无需赘述，甚至有程序员认为，TortoiseSVN就是SVN本身，一提到小乌龟，每个码农都会心一笑。而且，SVN本身的命令行客户端，就已经非常简洁好用了。跨平台简直毫无任何可以挑剔的地方。
简单易用。我个人认为，SVN的易用性是无与伦比的。我刚入职腾讯的第一年，身边的程序员，是把SVN当成云端文件夹用的。整个部门，只有一个版本库，一个项目文件夹，所有的项目代码仍在trunk里面，需要开新项目，就在trunk里加一个文件夹。就算SVN被误用到这种程度，它依然没有给整个研发过程带来任何大的麻烦，一切都井井有条。你要学会的，就是在小乌龟里点点鼠标而已。
后来，部门逐步扩大，文档增多，为了保护文档不丢失，部门运维自己架设了一个SVN服务器，让所有非程序员成员，都用SVN管理文档，各种需求，设计稿，统统用SVN管理，这个切换过程几乎没花什么时间，就是简单地给一些非技术同事培训了一下，一切都平滑异常。让五、六十号不懂技术的人，一下子用上SVN，足见其简单了吧。
功能完善稳定。从过去七年(此时是2015年)的开发经历来看，我还没遇到过什么SVN不能处理的研发管理模型。特指在中国，公司制的研发团队管理场景下。SVN本身建议的研发流程模型，已经足足够够了，trunk用于代码主干，branches用于特性开发，tag用于发布快照，一切都流畅自然。
我所在的团队，经过几年的摸索和磨合，已经形成了非常流畅顺滑的研发流程。有新任务来了，开分支，天天早上第一件事，同步主干变更(sync trunk)，任务完成后，分支测试，测试完毕后回归主干(reintegration)，完毕后集成测试，测试通过后，打tag，然后用内部自研上线系统，tag全量代码发布，最后分支负责人删除掉用过的分支。尤其配合SVN 1.5以后出现的merge tracking功能特性，连冲突都是很偶然的事件了。
SVN经过15年左右的研发，功能异常完善，而且非常稳定，你熟知的命令和参数，就几乎一直保持着你熟知的那个状态，没有附加学习成本，最难能可贵的是，SVN一直在持续更新，改善效率。
git 相对SVN来说，有什么缺点？
高昂的学习成本。不要睁着眼睛跟我说，git学习很简单啊，“学习很简单”这一个主观感受，也即，你觉得简单，只能代表你一个人的感受，如果整个团队只有你一个人，或者你们团队奉行一种精英文化，不是精英不招聘的话，你们所有人，可能都觉得学习git很简单。但是如果是一家刚刚创业的小公司，或者经营数年的中小企业，考虑其本身能从市场上获取到的人才的程度，你不得不考虑他们的接受能力。固然，公司可以花力气去培训，可是培训的时间和代价，本身就构成了“学习成本”。
拙劣的跨平台支持。对于Windows，尤其不友好。但是请注意，Windows仍然是世界上使用最广泛的操作系统，我相信，大多数基层程序员也仍然在Windows环境下工作，那么git那近乎故意的Windows不友好，不知道到底是为了什么。无论GitHub做了什么，各种IDE做了什么，在Windows下使用git，其体验仍然是非常间接，而且不方便的。
糟糕的抽象，复杂的结构。要想用好git，用户必须理解几个很特殊的东西，一个是分布式的结构，另一个是git存储版本的原理。这对于没空去理解他的人们来说，很不友好，你几乎不能凭着直觉去使用git，那样几乎都会把事情搞得一团糟。另外，公司里非技术的同事，几乎没法使用git工作，比如我们公司的设计师，试图使用git来管理设计稿，并进行协作，实际体验是很糟糕的，他们连新建版本库都不会。还不用提git其实对二进制文件并不怎么友好。
你可以把事情搞得很糟糕。git整个系统，给用户提供了极大的自由度，很多操作，我们知道是危险的，但是系统并没有阻止你操作。比如，你可以把任意分支push到任意分支，比如你可以随意删除本地提交历史里的commit，比如你可以把多人共享的分支给rebase掉，你可以干出很多匪夷所思的坏事托乱全团队的速度，你可以惹麻烦，git本身没有提供任何保护机制。
一个不是结论的结论
我完全站在SVN的拥泵角度，来阐述上面那些，我会得出这样的结论，SVN在某些场合，真的比git更合适，而我觉得，这个结论，也相对是公允的。如果公司研发成本低，研发团队小，研发人员经验参差，完全应该考虑直接使用SVN，这可能为你们团队后续发展，节省大量的时间。
当然，还有一个要考虑的因素是研发内容的特点和研发流程的特点，是否高频次协作？是否跨公司，跨地域协作？是否海量研发人员参与的开源系统？而就我的经验看，很少有公司的研发团队能跟这些东西搭边，于是SVN理所当然成为更理智的选择。 - storespace0930
- swsh007估计你这团队成熟型程序员比较多，或者windows平台开发为主。
svn挺好用的，没必要跟风。 - HHH去中心化好处就是你想开多少分支就开多少分支，而且只要不push绝对不会影响其他人。svn我们公司只用来当储存系统来用，但另外用的微软TFS功能类似的，一个很麻烦的就是别人lock了文件你就懵逼了，git没这问题，因为都是你自己搞的，最后push上主branch而已。而且git因为随开bransh，你也很容易分branch来做自己工作。我经常碰到场景就是正在做一个feature，突然间hotfix来了，我在这个branch上的所有改动都要退出来优先做hotfix，git就很容易了，随时开个hotfix branch就行，而且不影响正在进行的feature，也不影响其他人的工作。
- storespace0930回复42#HHH
hotfix这个svn也是可以实现的。假设你手头正在干的事在分支A上，现在来了hotfix需求，你马上把分支A上的活提交掉。然后开一个hotfix分支，切换过去修代码，然后提交后再切换回分支A。整体流程以及效率和git并没有什么区别，唯一的区别在于，你提交到分支A的代码可能是半成品，可能会影响其他人，这是个缺点，但是写好备注，还算能接受。 - storespace0930
- 张小敬企业环境下大多数情况用svn更合适
- HHH回复43#storespace0930
可以做不代表做得好，git在灵活性方面比svn要好。当然我用SVN不多其实也没他多资格说SVN的，但公司里的人都不傻。就你说的这个场景会影响到其他人，git下面基本上可以保证你code不完成不会push。
git的灵活性还在于，你不需要特定一个服务器装git，下载个git开git bash就能用。开对开发来说非常友好，因为中心化的source control要开branch要merge都得等人因为权限不够，git没这麻烦，公司可以控制主要branch权限，但开发也能自己控制自己code branch，谁都不会受影响。
git还有跟其他工具融合性很高，而且也有云服务提供商，svn作为一个SD不差，但没有不可取代性，git反而变成一个SD标准了，连微软都要扔掉自己的TFS搞git就说明这两个东西不是一个位面上竞争的。 - BuleGood想起一个悲伤的事，之前一直用svn后来去了一家新公司，用的git，问了下旁边同事，怎么操作，结果同事去找了老板，说我不行，连git都不会用。小尾巴~
- HHH
- storespace0930回复46#HHH
确实git很火热，因此我们也很感兴趣。但是如果说其他人都不傻，因此我选git，这个理由其实很难接受。我反而觉得人云亦云的太多，需要有实际案例来分析证明，这也是我发这个贴子的目的。
经过学习大家的意见，基本上大家认为git的优势还是在分布式和本地库上。但是分布式在企业内网环境压根没必要，本地库确实是个好东西，不过似乎现在有个git-svn可以用来实现这个功能。那么开发人员可以在本地使用git，提交到服务器还是使用svn，如果他愿意的话。
就分支来说，其实和svn并没有什么不同，网络大把文章说的分支合并性能和资源浪费压根就不存在，那些文章也从来没给出案例和对比数据。
可能是各个公司工作内容和开发环境的差异，导致了选择工具的差异。我现在觉得svn对于企业内部开发还是合适的。后续如果我们转到云上，可能切到git会更合适些。 - storespace0930