分支上线规范

分支命名规范：

1.修复bug分支命名规范：

{tagName}_bugfix_{bugfixId}，其中tagName：为对应服务上最近一次发布的tag的名称；bugfixId：为禅道上修改的bug的ID。

举例说明：

order服务要修复禅道上ID为1123的bug，当前order服务最近一次发布的tagName为release_200403,则对应修复bug后的分支命名为：release_200403_bugfix_1123。

备注：禅道上没有对应的bug对应的ID,要求测试人员根据bug内容建出。

2.新功能上线分支命名规范：

{tagName}_function_{version}，其中tagName为开始开发新版本时对应服务上最近一次发布的tag的名称；version为该版本上线发布的版本号。
举例说明：

order服务需要启动开发新功能，启动开发时当前order服务最近一次发布的tagName为release_200403，该功能的版本号为：v2.1.0，则对应的新功能上线分支的命名为：order_function_v2.1.0。

3.下次发布分支命名规范：

{tagName}_publish_{date}，其中tagName为对应服务上最近一次发布的tag的名称；date为该版本下次发布日期，例如下次发布日期为2020年04月14日，则date为：200414。
举例说明：

order服务下次上线的日期是2020年04月14日，当前order服务最近一次发布的tagName为release_200403,则对应的下次发布的分支名为：release_200403_publish_200414。

4.上线tag命名规范：

release_{date}，其中date为该版本发布日期，例如2020年04月14日，则date为：200414。
举例说明：

order服务今天上线，今天的日期是2020年04月14日，则对应的分支名为：release_tag_200414。

分支合并规范：

1.修复bug分支合并发布流程规范：

(1).从对应服务最近一次发布的tag中拉取一个新的分支，命名规范为按照bug修复分支命名规范要求。
(2).bug修改完成后，将该bug分支提交测试人员进行第一轮测试；
(3).经测试人员进行第一轮测试通过后将该bug分支合并到下次需要发布的分支（如果分支不存在，则由测试人员通知对应服务的owner负责建立，命名规范为下次发布分支命名规范），测试人员进行第二轮测试；
(4).第二轮测试通过后由测试人员向java架构师或架构师指定的负责人发起分支合并请求，合并到master分支进行第三轮测试；
(5).上线发布当天，由java架构师或架构师指定的负责人从master 打出一个tag进行发布，tag命名规范符合上线tag命名规范。

2.新功能上线分支合并发布流程规范：

(1).新功能开发完成后，提交新功能分支并通知测试人员进行第一轮测试；
(2).经测试人员进行第一轮测试通过后，将该新功能分支合并到下次需要发布的分支（如果分支不存在，则由测试人员通知对应服务的owner负责建立，命名规范为下次发布分支命名规范），测试人员进行第二轮测试；
(3).第二轮测试通过后由测试人员向java架构师或架构师指定的负责人发起分支合并请求，合并到master分支进行第三轮测试；
备注：这里主要解决tag不一致可能导致的冲突问题。
(4).上线发布当天，由java架构师或架构师指定的负责人从master 打出一个tag进行发布，tag命名规范符合上线tag命名规范。

备注：原则上bug分支和功能分支不在同一期发布。