svn/git代码管理规范，多Target工程适用
以svn为例，git同样适用。
注意事项：
⚠️配合SVN分支记录开展，记录每个分支进度，状态、最新代码所在位置等。
⚠️确保每次提交后，工程可以正常运行，造成代码无法运行的部分需要放在一起提交。
⚠️所有代码的合并，都尽可能的使用CherryPickChanges，选择commit版本号方式。
⚠️合并出现文件冲突，需要备注：解决文件了哪些文件冲突。
⚠️合并分支使用格式：合并了哪个分支+commit版本号。
Merge NewTaskBranch 分支 2708、2712
Feat（直播页面）：新增屏幕旋转。
⚠️跟进大量主分支代码，尽量删除分支重建保持代码一致性。
⚠️导出任意commit版本号代码
一、 目前开发现状
1、 一个Project中包含多个Targets开发。
2、 每个target有单独的配置文件，其他代码都是共用的，代码中包含对target的判断和对产品设备的判断。
3、 svn中develop_XuJiahui包含几乎所有的代码，原计划合并上线版本代码，实际中会有偏差。
4、 新需求开分支开发。
二、 SVN代码管理问题
1、 上架一个版本，其他版本如果跟不上就会出现代码版本落后的情况。
2、 落后版本B要继续上架，需要在某个A上架版本上去开发合并。现状是A版本后期已经陆续开发了需求，修改了历史bug。
B版本虽然可以在A历史中开出Branch，但是A后期修改的bug由于提交代码不规范，造成合并过来工作量大，后期合并主分支困难的情况。只有再次解决bug来规避不必要的麻烦。
3、 A上开发了新需求，还未上架。此时B需要上架A的需求，不同的branch包含相同的代码，后期合并会有困扰。
4、 种种代码交叉开发、合并的问题随时出现。
三、应对方案
1、 commit单一化：
保持提交当次的commit代码类型单一、代码范围纯净（需求、bug只能存在一个，新老UI问题分开提、文件数量控制：
提交需求，代码中只能包含单个需求代码；
提交bug，代码中只能包含bug的修复代码；
2、commit规范
commit内容包含：
类型:（Merge代码，需要commit记录）
(影响的范围): 内容概述
例如：
Merge NewTaskBranch 分支 2721-2723
Fix: 2721-2723
1、 (自研单目清晰度)：清晰度只有两个选择项；
2、(自研双目新ui清晰度)：清晰度只有两个选择项。
Res：2722
1、（双目新ui对讲）：添加对讲按钮选中状态icon。
type通常是以下几个：
● Feat: 新功能、特性
● Fix: 修改问题
● Add：新增资源、文件、分支
● Del：删除资源、文件、分支
● Refactor: 代码重构
● Docs: 文档修改
● Res: 添加和修改资源文件
● Style: 代码格式修改,
● Test: 测试用例修改
● Merge：合并稳定版本/分支/冲突等
● Revert(2731)： 回滚到2731版本
● Pod： 修改pod相关
2、多分支管理Target
每个项目保持一个分支；
每个需求开启一个临时分支（需求稳定后->合并主分支->可以删除，此后轮为bug处理）
3、 iOS举例：
develop_XuJiahui 是一个主分支 ，只包含：稳定代码。
1、创建target分支（用于版本打包测试，解决历史bug）：
develop_living
develop_reCard
develop_Message
.....
需求分支：
reCard_FeatJILian reCard 上开展 JILian需求
2、reCard需要开发JILian需求
develop_reCard branch reCard_FeatJILian
1、需求中需要commit提交，使用Feat。
2、 开发完整的需求后需要打包测试了，reCard_FeatJILian 合并到 develop_reCard；
Marge reCard_FeatJILian 1000-1010
Feat（影响范围）
1、JILian 需求制作
3、测试过程中版本迭代：
1）历史bug在develop_reCard中提交；
2）新需求bug，还是要在reCard_FeatJILian修改后 FIx 合并到 develop_reCard。
......
4、版本过测，上架后合并代码：
1）将此版本修复的历史bug通过多选commit方式，Marge + Fix到 develop_XuJiahui，commit记录尽可能的有修改信息。
需要分开合并的也要分开Marge + Fix/Feat。
5、其他版本的需求提测：例如：_Lenovo 1）、根据当前版本的Log记录查看commit版本是否落后于develop_XuJiahui，需要了合并Fix修改记录；
2）、_Lenovo需要在develop_reCard提测版本中合并Fix，可以直接在其他版本Fix过来即可。
3）、_Lenovo需要合并reCard_FeatJILian，Feat reCard_FeatJILian到_Lenovo；
4）、测试中_Lenovo中修改历史bug，reCard_FeatJILian中修改需求bug；
5）、稳定上架，_Lenovo发现修改的bug， Marge + Fix到 develop_XuJiahui；reCard_FeatJILian的bug Marge +Fix到
develop_XuJiahui。
6、丢弃新需求分支
当此需求，可以在全部target上使用/合入代码不影响其他target正常运行时；
可以删除reCard_FeatJILian，此后需求bug，轮为历史bug处理。
7、覆盖范围广，影响代码运行到冲突（需完善）
一次性解决，Merge到 develop_XuJiahui，下发到所有涉及的分支中/查看记录：打包时候合并代码；
实践中：
多人在主分支开次分支进行开发需求-提包-解bug的现象管理；
因为每次上架都会打tag；
这个时候主分支可以实时合并其他分支修改代码，来协调管理公共部分的代码，防止一个bug多人修改后衍生出更多的问题以及后期的代码合并造成困难；
*feat功能都要有开关；
*合并过程中，有冲突打部分都要保留冲突代码（注释掉），在下方处理冲突；
*分支开发中，禁止大面积打修改一个类，如果需要修改，需要测试无问题后，让其他所有分支都同步最新代码块；
提测打包，都要从主分支开始，同时发现处理合并中出现打问题；
全面测试通过才可以删除保留冲突打代码。
