分支管理规范

最近有机会体验下阿里的云效产品，感受下"大厂"的DevOps产品。在写这篇Blog时，正正好赶上了《阿里云效公共云基础版全面免费，不限人数使用》，基本可以白嫖了，为双十一做的贡献，终于有回报了。

估计应该由小伙伴为此纠结过吧，其实吧分支管理规范没有 ”银弹“ ，这里我只是分享我觉得比较简单也是对持续交付较为友好的 GitHubFlow + Tag 分支模型。

重要的事儿还是需要在说一遍的：分支管理规范没有 ”银弹“！

1、分支管理模型

推荐 GitHubFlow + Tag 分支模型，不推荐GitlabFlow （Please stop recommending Git Flow!）

GitHub flow，是 GitHub 所推崇的 Workflow，具有很高的通用性，且叫简单快捷，对持续交付较友好。其流程图如下：

其中的主要流程为：

第一步：根据需求，从稳定分支master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个 Pull Request 或 Merge Request（简称PR 或 MR ）。
第三步：PR 或 MR 既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码（CodeReview）。对话过程中，你还可以不断提交代码。
第四步：你的PR 或 MR 被接受，合并（Merge）进master，重新部署（Deploy）后，原来你拉出来的那个分支就被删除。（备注：其中先部署再合并也可。）
第五步【打Tag】：在第四步的合并（Merge）后打上 Tag，基于 Tag 进行部署（Deploy）。

2、分支命名规约

分支	描述	备注
master	稳定分支，这个分支只能从其他分支合并，不能在这个分支直接修改	需要遵循一个基本原则，所有在`master`分支上的`commit`应该`tag`
feat/*	功能特性分支
fix/*	Bugfix/Hotfix修复分支
tag	上线发布的Tag号，符合语义化版本约定

3、提交命名规约

任务ID： EE-233   // 对应JIRA Issue编号，可以自动实现Jira与Gitlab的提交关联``提交内容： [feat] 功能特性开发``     ``[fix] 修复Bug``    ``[``rm``] 删除无用文件``    ``[ref] 代码或功能重构

4、CodeReview规约

提交MR

提交代码后，可以提交mr到master，申请合并代码。（此处可进行自动代码审查）

合并代码

研发组长（或结对编程小伙伴），打开MR，Review代码，可以添加相关修改Comment意见。

开发同学根据建议修复代码，或者线下修改后commit代码。

研发组长确认没有问题后，可以合并到master，并打上对应的标签。

5、版本号命名规约

参考《语义化版本 2.0.0》

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。

先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

6、上线规范

所有上线的制品是基于 Git Tag 构建产出的制品。

7、Commit Message提交规范

参考：约定式提交 1.0.0-beta.4

目前有相应工具做到支持：commitizen & cz-conventional-changelog 、 git-commit-plugin等

基本提交格式：

<类型>([可选的作用域]): <描述>
// 空一行
[可选的正文]
// 空一行
[可选的脚注]

提交示例：

1
2
3

feat/fix: 完成一个很牛掰的功能开发/修复一个极度危险的Bug
 
re/fix  #EE-123 #EE-333

约定说明：

1. 类型 - type

type为必填项，用于指定commit的类型，约定了feat、fix两个主要type，以及docs、style、build、refactor、revert五个特殊type，其余type暂不使用。

# 主要type
feat:     增加新功能
fix:      修复bug
 
# 特殊type
docs:     只改动了文档相关的内容
style:    不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build:    构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert:   执行git revert打印的message
 
# 暂不使用type
test:     添加测试或者修改现有测试
perf:     提高性能的改动
ci:       与CI（持续集成服务）有关的改动
chore:    不修改src或者test的其余修改，例如构建过程或辅助工具的变动

当一次改动包括主要type与特殊type时，统一采用主要type。

2. 作用域 - scope

scope也为必填项，用于描述改动的范围，格式为项目名/模块名，例如：node-pc/common rrd-h5/activity，而we-sdk不需指定模块名。如果一次commit修改多个模块，建议拆分成多次commit，以便更好追踪和维护。

3. 正文 - body

body填写详细描述，主要描述改动之前的情况及修改动机，对于小的修改不作要求，但是重大需求、更新等必须添加body来作说明。

4. 注脚 - affect issues

affect issues指明是否影响了某个问题。例如我们使用jira时，我们在commit message中可以填写其影响的JIRA_ID。

参考：准时下班的秘密：集成 GitLab && JIRA 实现自动化工作流

填写方式例如：

1 2	re #JIRA_ID fix #JIRA_ID