版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/q623702748/article/details/79954455
如果你们公司的项目代码是用svn来进行统一管理的，但是你又想使用git的开分支功能进行本地管理的，那么以下的介绍将会给你些许提示（如果有更好的解决办法，欢迎大家提出）
情景描述
：我们开发人员的一个理想开发的流程，就是【序列化】开发一个个需求，然后与前端联调，差不多就提交到svn代码。但是，实际上我们可能遇到的不一定都是序列化的。
以下内容是为了说了本地使用git分支的好处，若知道可以直接跳过
情景一：
当A开发【角色法宝】需求做到一半，还没自测，这时候测试反馈说【角色技能】模块出bug了。你不得不停下手上需求开始解决bug文件，但是A的代码写到一半，代码还没能通过编译，自身正在开发的代码又可能因为协议变化或者修改与bug相关的文件，肿么解决？
传统纯使用svn思路一：
1、尽快解决自身需求内容，先让其能够编译通过，并且不影响其他人正常测试，并且提交到svn上，再开始解决bug。
2、因为公司的svn正常只开放trunk目录权限，并且大部分的公司也很少允许我们在远程的svn建立自己的分支，所以为了更快处理问题。直接checkout一个无污染的项目代码，开始在上面找问题。
传统纯使用svn思路一存在弊端：
1、开发人员不得不为了让内服正常执行，而做出一系列对
内服的操作，如修改测试用例不让其报错，清档或者是转换旧数据……但是这些都会影响开发人员不能第一时间去处理存在问题（如果是紧急问题，将会影响更大）。
2、【传统纯使用svn思路2】的策略对于回馈bug确实比思路一好，但是本地又要多维护了一个目录。久而久之，本地可能会出现十多个目录，这样的也是不利于寻找问题的。
情景二：
当后端B开发完成【帮派】功能了，并且写了部分测试点测试，但是前端还没开始开发，后端想开发其他需求，肿么办？
传统纯使用svn思路二：
1、代码留在本地不提交至svn，然后开始做其他需求，等前端完成了，再开始回过头来跟前端联调。
2、提交代码，并开始开发其他需求。
传统纯使用svn思路一可能存在弊端：
1、当开发其他需求，有可能会出现修改同一个文件（如脚本自动生成的文件cfg_init_module.c），这时候提交代码又要考验开发人员的眼力了，一不小心，一个需求单子，可能提交了两个需求的一小部分内容（影响后续迁版本合并操作）
2、这种开发应该是我们开发中很常见的方法，但是会有潜在问题。
新需求有可能写到一半，后端其他同事说XXX功能出问题了，请修复一下。（影响到其他人正常体验）
或者发现自己原本觉得可以的数据结构突然发现不太适合，但是已经提交到debug了。只能清除该需求的数据。（如：开发的是将领羁绊，但是数据又存储在将领总数据中，这时候还要清除将领数据才能正常执行，影响非常大。）
说了这么多，其实就是为了说明在本地使用
git的分支效果的便捷性，如果我们在本地使用git来管理我们svn代码，将开发多个任务时候将得到更好的技术援助：
应对原情景一：
非常方便，任何一个新开发的需求都在master中开分支，测试说将领职能模块出问题了。
1、我们只需要暂时commit一下法宝的代码（存档）
2、切换到技能分支，更新一下代码（读档），
3、修复技能存在问题（类似升级打怪兽）
4、合并到master，提交代码（完美通关）
5、重新切换到法宝分支（重新读档，继续通关）
master
* role_talisman-1.0（法宝分支）
role_skill-1.0（技能分支）
本地使用git分支好处：
1、代码不需要保存多分，由git替我们管理
2、随时读档随时存档，类似你有无限后悔药进行操作
应对原情景二：
1、建立分支，定时存档就可以了。
好处：
1、各个需求代码相互独立不影响，测试起来未知影响的因素会减少
因为权限原因，所以我们本地不能使用svn的分支功能，但是用git本地也能很好替代这一因素，可见git在单刀攻坚（本地个人开发）还是挺强大的。
分享一下自己常使用的git指令(其实这些大部分ide都集成了，可以不用手敲)：
1、git拉取svn仓库： git svn clone <svn的仓库地址（如
https://<svn仓库地址>/server/trunk）>
2、git 建立分支 : ① git checkout -b <新的分支名> ②git branch <新的分支名>
3、删除分支git branch -d <分支名>
4、检测是否有更新类似svn update：git svn rebase
5、更新代码 git svn fetch
6、git合并分支，类似svn，略
7、git提交到远程svn仓库：git svn dcommit