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
合并请求
-
在GITLAB上的相应仓库,选择请求合并,并点击新建合并请求 [New merge request]。
-
选择Source Branch ,即被合并的分支,选择Target branch,即合并到哪个分支。
-
在新的页面中,填写标题、描述、指派给谁批准等,然后提交请求就好。
-
- 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