【无标题】

GIT 管理规范

分支规范

名称	权限	必须	描述
release	管理员	✅	主干分支，永远与线上版本保持一致，每个部署环境对应一个release分钟
uat	管理员/开发人员		预发布分支
test	管理员/开发人员	✅	测试分支，用于提测使用
demo	管理员/开发人员		多分支合并的分支，用来多功能演示
develop	管理员/开发人员	✅	开发分支，是新而全的新分支，能运行但不稳定
feature	管理员/开发人员		功能分支，当有新需求时，可以master建立分支feature分支
hotfix	管理员/开发人员		修复分支，从release拉出此分支

场景分解

• 启动开发

负责人	操作
开发人员	创建develop分支
开发人员	初始版本同步和提交develop分支

• 功能开发

负责人	操作
开发人员	根据任务建立相应的feature分支，请参照分支命名规范，多人同时开发时，可建立多个feature分支，开发中随时进行提交
开发人员	功能分支开发完毕后，若功能需要上线，则转成test分支进行提测 ，若功能不需要着急上线，则合并到develop分支

• 测试上线

负责人	操作
开发人员	测试通过后，可以将test分支合并到release分支，并部署代码；若有预发布环境，则先合并到uat分支，再从uat合并到release分支
开发人员	正式版本上线，上线成功后，需要对分支打上tag
管理员	成熟项目，release分支需要管理员review
开发人员	线上问题稳定后，需要把release分支合并回develop分支

• BUG 修复

负责人	操作
开发人员	从release创建hotfix分支进行修复
开发人员	修复完毕后，测试通过后，从hotfix合并回release

特别约定

• release分支只接受合并（merge），不接受提交（commit）
• develop分支是一个新而全的分支，只要代码能够编译，就算有bug也可以合并，尽可能频次高的合并
• feature分支推荐从develop分支拉出，除非是特定版本的迭代，可以从release分支拉出
• feature和hotfix分支完成使命或，三个月内没有修改，需要删除分支
• feature分支若开发时间太长，需要从develop分支合并最新特性

分支命名规范

feature分支采用特性功能+任务描述+分支创建人拼音全写
hotfix分支采用特性功能+时间+分支创建人拼音全写

例子：

• 张三：zhangsan

feature命名规范：分支类型/任务描述/开发人员简称
hotfix命名规范：分支类型/年月日/开发人员简称

例子：

• feature/portal-banner/zhangsan
• hotfix/20230203/zhangsan

合并请求

1. 在GITLAB上的相应仓库，选择请求合并，并点击新建合并请求 [New merge request]。

2. 选择Source Branch ,即被合并的分支，选择Target branch，即合并到哪个分支。

3. 在新的页面中，填写标题、描述、指派给谁批准等，然后提交请求就好。

• • Assignee 就指派谁来批准请求，默认就好。
  • Milestone 即里程碑，默认就好。
• • Labels 项目标记，默认就好。
  • 合并选项，这个勾指的是“是否合并后删除source branch”，如果此分支可以删除就打勾吧

更新日志

更新日志写法规范
每次发布都需要写更新内容

说明：
版本：1.0.0：此次发布上线的版本号
节点：812dba7784703d6e55dcb104313be0f73bf74241：每次commit或merge分支后的节点 ID
提交人：@realm：该功能开发者，通过@可关联 GitLab 上的用户帐号

commit id获取方式：
1.可通过git log查看
2.可通过GitKraken工具复制节点的 commit id
3.可到 GitLab 仓库提交历史中复制 commit id

## 2020-08-01

> 版本：1.0.0  
> 节点：812dba7784703d6e55dcb104313be0f73bf74241  
> 提交人：@realm

### 新增（Features：新增功能）

- 事项描述 A
- 事项描述 B

### 修复（Fixed：修复 bug）

- 事项描述 A
- 事项描述 B
- 事项描述 C

### 变更（Changed：对于某些已存在功能所发生的逻辑变化）

- 事项描述 A

### 优化（Refactored：性能或结构上的优化，并未带来功能的逻辑变化）

- 事项描述 A
- 事项描述 B
- 事项描述 C
- 事项描述 D

### 即将删除（Deprecated：不建议使用 / 在以后的版本中即将删除的功能）

- 事项描述 A

### 删除（Removed：已删除的功能）

- 事项描述 A
- 事项描述 B

版本号管理

采用三段式版本号，即a.b.c的形式。

版本号递增规则：

c自增：bug修复&当前功能修改。

b自增：功能增加。

a自增：非兼容性大版本更新。

例子：

原版本号：1.0.3

修复一个BUG，版本为1.0.4

新增一个功能，版本为1.1.0

新增二个功能，版本为1.3.0

技术上发生了变革，更新了一个版本，2个版本不兼容，版本为2.0.0

---