分支提交规范

一、现状

1、枝节蔓生、到处都是分支，完全看不出主干发展的脉络。
2、特性分支过多造成代码冲突，合入代码成本高
3、每次提交涉及多个分支或内容过多，review成本大
4、由于某些因素Master分支不能立刻发布，导致代码回退或拆分困难。
5、master或develop未加锁保护，测试完成后开发又将未开发完成的其他不相关代码pull上去，测试未知情的情况下直接打包发版，造成重大问题
6、分支名称相似，合错代码

二、Git分支介绍

1、主分支Master

从项目创建之初，有且唯一的主分支，所有提供给用户使用的正式版本，都在这个主分支上发布，Git主分支的名字，默认叫做Master

例如：张三向master分支merge了代码，那就意味着张三完成了此项目的一个发布的版本。所以master分支不是随随便便就可以签入代码的地方，只有计划发布的版本功能在develop分支上全部完成，而且测试在Release分支上测试完成没有问题了才会合并到master上。

2、开发分支Develop

develop分支是开发过程中代码中心分支。程序员要以develop分支为起点新建feature 分支，在feature 分支中进行新功能的开发或者代码的修正。也就是说develop分支维系着开发过程中的最新代码，以便程序员创建feature分支进行自己的工作。

例如：张三要开发一个注册功能，那么他就会从develop分支上创建一个feature分支【 feature-20220427-zhangsan-注册功能】，在feature-20220427-zhangsan分支上将注册功能完成后，将代码push到develop分支上，解决冲突。这个feature-20220427-zhangsan就完成了它的使命，可以删除了。

3、测试分支Release

release分支是测试中心分支，不允许直接签入代码。开发把功能完成后push到develop解决冲突，然后合并到release分支

例如：张三开发完成了注册功能，李四完成了新增项目功能，张三和李四把代码从feature分支push到develop分支解决冲突，然后进行开发自测，完成后将代码merge到release分支【 release-20220427-效能4月优化迭代1】，测试从该release分支拉取代码构建、部署进行测试。

4、临时性分支

除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有二种

功能（feature）分支
热修复（hotfix）分支
这二种分支都属于临时性需要，使用完以后，应该删除

4.1、功能分支-feature

功能分支feature，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop，feature 分支以develop分支为起点，是开发者直接更改代码发送提交的分支。

例如：

张三从develop分支创建feature分支

从feature分支中实现目标功能
push至develop分支解决冲突
完成后merge至测试分支release-*

4.2、热修复分支-hotfix

hotfix是快速给已发布产品修复bug或微调功能的分支，修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用hotfix-*的形式。
在hotfix分支下进行工作：
release 版本中发现了bug 或者漏洞
develop 分支正在开发新功能，无法面向用户进行发布
漏洞需要及早处理，无法等到下一次版本发布
假设有问题的版本是1.0.0，修复BUG 后的版本至 1.0.1
现在以1.0.0的标签信息为起点，创建名为1.0.1 的fixbug分支。
修复工作结束后，将hotfix分支merge 到master分支和develop分支

三、分支规范

3.1、分支WorkFlow

3.2、分支命名规范

Type-Date-Domain-Description
Type：描述分支的类型，仅包括feature和hotfix两种
Date：统一使用8位表示，单月/单日使用0补齐
Domain：使用公司统一域账号表示
Description：一般一个分支对应一个功能，该处使用简短的语句描述清楚提交的功能或修复的缺陷
示例：
feature-20220427-张三-项目初始化
feature-20220427-李四-多组件项目构建接口
bugfix-20220427-王五-用户鉴权缺陷调整

四、分支提交流程

五、分支工作的生命周期

六、代码提交日志规范：

编写日志的目的：为了后续查问题；持续集成系统会整和日志以形成构建记录，省去人工整理,同时也能为绩效考核提供参考