为什么会有这件事
这个事情发生在三年前，当时刚进入新公司，公司有个CTO是从网易出来的，我来到公司没两周，就让我把公司的代码管理工具SVN换成Git。做运维和技术的都应该知道，这个代码库管理工具使用惯了，大家都会养成一种习惯，就是只用自己习惯的东西，为什么要去换。况且我也是刚进入公司不久，让我去把公司的代码库从svn换成Git，就是在动人家的祖坟，而且还会惹人烦。但是没办法，谁叫我们是做事的，所以当时只能硬着头皮想办法怎么去完成这个既有阻力，又有挑战的工作。
了解SVN和Git之间的区别，GIt的优势在哪里
我知道，如果我要带头将公司的SVN更换成Git，那么首先要我自己说服自己为什么要用Git，Git相对于SVN的优势在哪里，了解清楚这些之后，我才能在被质疑的时候说服质疑我的人。
现在就来简单谈谈两者的区别，至于谁优谁劣看官自己思考吧！
1）、最核心的区别Git是分布式的，而Svn不是分布的。Git跟Svn一样有自己的集中式版本库和Server端，但Git更倾向于分布式开发，因为每一个开发人员的电脑上都有一个Local Repository,所以即使没有网络也一样可以Commit，查看历史版本记录，创建项 目分支等操作，等网络再次连接上Push到Server端。
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只能有一个指定中央版本库。当这个中央版本库有问题时，所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。而 对于Git来说，每一个Git都是一个版本库，区别是它们是否拥有活跃目录（Git Working Tree）。如果主要版本库发生了故障，工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库！
8）、分支（Branch）在SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开啟新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来进行破坏工作（安检测试），那将会像传染病一样,你改一个分支，还得让其他人重新切分支重新下载，十分狗血。而 Git，每个工作成员可以任意在自己的本地版本库开啟无限个分支。
在了解和简单使用了git之后，做下简单的总结：
1）、SVN的特点是简单，只是需要一个放代码的地方时用是没有问题的。
2）、Git的特点版本控制可以不依赖网络做任何事情，对分支和合并有更好的支持(即使连接不到git服务器，比如在家办公提交代码也可以)，不过想各位能更好使用它，需要花点时间尝试下。
制定方案、计划，并与相关技术负责人讨论商量替换事宜
刚开始的时候，找了技术部门负责人讨论了SVN替换为Git的事宜，其实在他们这个位置上坐久了，也养成了一种安逸的习惯，我推这个事情，就是在动他们的工作基础。表面上仅仅是指就代码管理工具替换，但是实际上他们会改变他们的代码提交习惯，代码发版，版本控制习惯等等一些列连锁反应。
我也说明了我的立场，以及更换为Git的好处，对于这些优势，他们没什么好说的，在最后我也说明了这是CTO坚持要做的事情，希望他们配合。结果他们都没什么反对的（看来有时候做事不能一股脑的就去做，还要懂得利用靠山的力量~~）
git工具的选择
git的工具有很多，有最原始的git，有github，有gitlab。
Git – 版本控制工具
Github – 一个网站，提供给用户空间创建git仓储，保存用户的一些数据文档或者代码等
GitLab – 基于Git的项目管理软件
基于深入了解后，我发现原始的Git是完全字符界面控制的一个管理仓库，在权限以及可视化方面的存在不足，如果要我进行推行这个git，遇到的阻力可能会更大，而且主要是权限不易控制；Github是一个网站，专门给用户创建git仓库，是在互联网上的，一来对于公司环境的频繁代码提交操作，网络稳定性有待考究，提交代码的速度必然会较慢，最主要的是你把源码放在别人的磁盘上，这个想象都觉得不太安全，Github还是比较适用于个人开发者或者开发小团队；Gitlab是一个基于本地的Git项目管理工具，自带Web控制台，而且也有较为完善的权限管理，最终我选择了Gitlab作为替换SVN的代码管理工具。
替换前的准备工作
试想一下，如果开发人员是SVN的爱好者，一直都是用SVN，对Git一无所知，如果在这样的情况下，你没有任何的准备工作就执行替换工作，那你让这些对Git一无所知的同事如何是好，结果可想而知，那就是怨声载道。既然你已经想到可能会有这样的情况发生，你如果想这件工作完成得漂亮一点，那是否就需要准备好一份培训文档？
没错，我在替换前，就已经将Gitlab的培训使用文档变编写好了。其中主要的内容包括以下：
1）、Git 简介
2）、账号申请
3）、客户端安装
4）、SSH key使用(Mac)
5）、SSH key 使用（Windows）
6）、新建项目规则
7）、项目检出check
8）、创建分支branch
9）、代码提交Commit
10）、代码拉取Pull
11）、代码推送Push
12）、代码标签tag
13）、代码冲突解决
14）、创建忽略文件
顺利将公司SVN替换成Git
我选择的一个切换时间是下班7点钟的时候，在此之前我们在公司群发了通告，任何提交到SVN代码的操作必须要在7点钟之前提交完成，否则则无法再进行提交。
到了7点钟，我们使用拷贝代码的方式进行了git项目创建和上传新项目，git用户的创建以及添加，创建完成后。根据已收集到的用户以及项目权限表进行了git用户划分。时间持续大概2个小时。
第二天一早，虽然我们已经将预计的工作完成，但是还是会有些人大呼小叫，这有问题那有问题的，总结下来，其实就以下几类：
1）、未登录web控制台进行秘钥输入，导致无法进行验证拉取代码；
2）、秘钥生成方法有误，公钥和私钥傻傻分不清；
3）、sourcetree等开发人员代码管理工具未设置秘钥；
4）、提交代码的步骤有误，需先提交到本地仓库，才能提交到远程服务器git仓库；
后续
上述只是简单记录了我是怎样将公司SVN替换成Git的过程，并未对相关部署行为进行详细描述，后续有时间的话，我会进行整理，整理完成后会再分享出来给大家。最后再说重申一下，其实Git是个好东西，的确是值得花时间去改变。
