使用git分支管理的操作说明
一、各分支使用用途
1、master：主分支，线上只能从此分支发布出去，一般情况下不能直接在此分支修改代码，特殊情况需审批说明原因
2、develop_merge：开发阶段大集合分支，之所以需要此分支，是因为目前测试环境只有一套，多人协同开发的时候，大家需要汇入这个分支，再统一发测试环境
1）、作为开发阶段的大集合分支使用，测试环境work站点从此分支发出去，杜绝直接在此分支修改代码并commit，只能从其他分支提PR，然后 merge 到此分支；
2）、管理员会每天用最新的 master 分支覆盖此分支，以保证此分支最新；
3）、待此分支阶段性的功能都在work环境测试通过后，合入Master分支，再从Master分支发到线上
4）、如果在此分支阶段测试出Bug了，需要修复Bug，也不允许直接在此分支上修改代码进行commit 和 push，应该在自己的分支上修改，然后再提第二次PR到此分支，如此反复，直到Bug消失
3、自己的开发分支：作为开发阶段使用，一旦代码PR并 merge 到 develop_merge 分支后，此分支应废弃删除（特殊情况保留，但一般保留时间不应过长）
二、各分支使用原则
1、每天拉最新的Master分支覆盖自己的分支，以保证自己的分支是最新，不要偏离Master太久，否则会给后期合并分支解决冲突带来困惑
2、自己的开发分支UT通过后，合并入 develop_merge 分支，待所有 Bug Fixed 且 本期的 develop_merge 合入Master后，可删除自己的开发分支
3、当前因为是多个项目并存一个git仓库 ，所以新开一个分支后，只能在此分支修改其中的一个项目，不允许一个分支修改多个项目，如果要修改第二个项目，请另外新开分支，因为以目前的管理方式，如果不这样做，会导致紧急进情况下如果要部分项目先merge到Master并上线，是做不到的。（这个在不拆分git仓库的情况下先这样实行，可讨论，未来肯定会按项目分仓库）
4、用完的分支，本地和远端都可以删除，避免随着时间的推移，分支太多，查找和识别麻烦
三、分支命名
1、{用途}_{责任人}_{需求名称}_{开分支日期}_
例如：feature_yongbuzhibu_OrderInfoEdit_20180328
四、提交代码的commit信息写法规范
1、格式：“[前缀]说明文字”（中英文不限），例如：“[Bug]修复了因用户为空导致的发优惠券失败问题”
2、其中的前缀可选项包括但不限于：
1）、[Bug] # 表示此次commit是修复了一个Bug
2）、[CodeReview] # 表示此次修改是因为他人给你做CodeReview提出的修改意见，你修复后再次提交
3）、[Feature] #表示完成了的新功能（或需求）
4）、[Refactor] #表示此次提交的原因是对代码做了重构
5）、[Format] # 表示此次commit是格式化代码或删除了一些无用文件等，总之未修改代码逻辑
6）、[Conflict] # 表示此次提交是解决代码冲突
...........
五、Commit 原则：
1、最小原则：完成了一个最小单位的功能就应该立即 commit，但可以不push，不能开发了一个完整的超大需求，再一次commit，这会让后来给你做 Code Review 的人无从看起或需要大量时间
2、描述清晰：描述说明文字简短、清晰，让人一看即懂