简介： 项目用的是 SVN 来做版本管理，但是用过 GIT 的我，实在是无法再次用回SVN，因为有一些使用习惯和代码安全感觉还是 GIT 更舒服，当然也可能是本人工作流程有问题
系统： Windows
诟病
在长时间使用 git 之后已经习惯了，已经习惯了随手 commit 代码的习惯，这样可做到尽可能多的保留代码版本，便于一些误操作，导致的代码丢失问题。
svn 使用简单，选择文件然后提交即可保存版本，但是简单也带来了一些弊端，举几个使用中遇到的比较难受的地方。当然也可能是作者不会使用svn的高阶功能导致的，如有读者知道更好地使用方法，也欢迎留言指导。
诟病点
- 分支的拆分
svn 分支需要将整个目录复制一份，就是说分支的文件是工程的副本，当工程大的时候，拆一次分支也是需要划分很多的时间来 copy 文件的。
git 拆分支，几秒钟，稍微慢一点，电脑卡一点，也就一分多钟，因为 git 不需要 copy 文件。所以，git 可以方便拆出很多版本分支，基本无额外消耗 - 分支的合并
svn 合并分支，我是用的项目提供的合并工具，然后输入单号，再根据单号查找对应的提交，然后进行合并。也容易漏，
git 合并分支，基本上在 gitlab 这样的管理工具里，没有冲突的情况下也是秒合，而且由于 git 拆分的便利性，所有的开发都可以按功能点拆分支，大家都在上面开发就行，到时候无需找单号，直接把功能分支合并过去即可，而且后期在功能分支上改了bug可以继续合并到主干。 - 分支长时间和主干分离
svn 由于合并的时候还是麻烦一些，所以主干不会经常合并到分支，这就容易导致分支的开发，在和主干合并时大概率出现冲突，那解决起来叫一个酸爽，PM 最近开会说我们这次合并分支用了两天时间，效率还是可以的，以后就走这个流程。 我已哭晕~~~。
git 由于和分支的便利性，可以随时将主干的变更合并到分支，分支开发者及时拉取变更，可以大幅度减少冲突的发生。基本上我之前的项目发四五个渠道，同时管理一大堆分支，和分支也就是几分钟的事情，遇到麻烦的情况也就小半天。 - jenkins 集成打包
由于svn的分支模式，导致我们要给不同的分支打包，就需要checkout不同的分支项目，然后打包，配置一堆的 jenkins 打包文件，那看上去叫一个专业啊。
然后每个分支再分几个平台的项目，酸爽。如果你想测的功能，提交上去打包还容易影响别人
而git的分支模式，使其只需要保留平台项目即可，打包时，通过设置可以自动切换分支，进行打包，就是可以在一个工程里打不同分支的包，这对于开发测试一些功能还是很有用的。 - 个人使用
在开发中难免会出现一些紧急任务，必须停下手里的代码，但是代码写到一半
svn 你不可能提交半成品的代码到svn,可能连编译也过不了，再整理，暂存或则存到别的地方，很是麻烦，而且有时候一不小心再删错了文件，还得重新写，老恶心了。
git 直接在当前工作分支切出一个分支保存当前所有工作成果，然后返回正常分支，处理问题，然后回来继续工作
主要是 git 你在本地无论提交多少次，只要不push，那么对其他人员是没有任何影响的，但是你却保留了自己开发记录。做测试代码，也可以切个分支出来，打包测完，能用就合并，不能用直接抛弃即可。
处理方案
由于以上种种原因，我想就算是工程用的SVN ，我也要用git来做一下本地版本记录，也便于自己的测试，和工作记录保留。
我的方案是，在工程外的其它位置创建一个空的git目录，通过文件夹链接的方式，将需要使用本地版本记录的文件夹添加到git目录里，然后在git目录进行本地版本记录，最终要提交时，再到 svn 目录进行提交。这样即增强了本地版本记录，也使得 svn 的提交更干净。
操作
我的工作项目目录在 C 盘，路径如：C:\MyProject
我的本地版本记录在 F 盘，路径如：F:\GITBake
然后windows下的目录链接指令时 mklink /j newPath srcPath
- 使用git小乌龟在空的 GITBake 文件夹创建一个 git 目录，我们的所有本地版本记录都会保存在 .git 文件夹下，如果有 gitlab 你还可以将其推送到gitlab进行一个线上备份
- 使用 mklink /j F:\GITBake\Assets C:\MyProject\Assets 命令，为C 盘工程内的 Assets 目录在 F 的备份目录内创建一个 Assets 链接
- 在 F 的备份目录内使用 git 的提交命令提交变更。
大功告成！！
