Rule 1. 【强制】gitlab 群组名称命名规范
名称全部小写，使用连词符进行分隔，群组深度最多二级
WARNING
cavalry ，water-balance
Rule 2. 【强制】gitlab 项目名称命名规范
全部小写，使用连词符进行分隔，并以公司缩写(jd,ninemax等)开头，前端以-web结尾，后端以-service 结尾，andriod 以 -andriod 结尾， 前端组件以 -front-component 结尾，后端组件以-backend-component 结尾，其它以自定义 -（自定义名称）结尾
| 项目类型 | 命名规范 | 示例 |
|---|---|---|
| 前端项目 | 以-web 结尾 | jd-aaa-web jd-aaa-yyy-web |
| 前端移动项目 | 以-mobile 结尾 | jd-aaa-mobile jd-aaa-yyy-mobile |
| andriod移动端项目 | 以-android 结尾 | jd-aaa-android jd-aaa-yyy-android |
| ios 移动端项目 | 以-ios 结尾 | jdaaa-ios jd-aaa-yyy-ios |
| 后端服务项目 | 以-service 结尾 | jd-aaa-service jd-aaa-yyy-service |
| 组件项目 | 以-component 结尾 | jd-aaa-front-component jd-aaa-yyy-front-component |
| 其它项目 | 以-xxx 结尾 xxx为自定义名称 | jd-aaa-tool jd-aaa-yyy-tool jd-aaa-map jd-aaa-yyy-map |
Rule 3. 【强制】git 提交规范
采用 Angular Git Commit 规范，Commit message 包括三个部分：Header，Body 和 Footer。其中，Header 是必需的，Body 和 Footer 可以省略。
其提交格式如下：
WARNING
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
header 通常只有一行，包括了提交类型（type）、作用域（scope）和主题（subject）。其中，type和subject是必须的，scope是可选的。
**type **提交类型，用于说明此次提交的类型，需要指定为下面其中一个
| type | 含义 |
|---|---|
| feat | 新增功能 |
| fix | 修复bug |
| docs | 修改文档 |
| refactor | 代码重构，未新增任何功能和修复任何bug |
| build | 改变构建流程，新增依赖库、工具等（例如webpack修改） |
| style | 仅仅修改了空格、缩进等，不改变代码逻辑 |
| perf | 改善性能和体现的修改 |
| chore | 初始化项目，非src和test的修改 |
| test | 测试用例的修改 |
scope 作用域 用于说明 commit 影响的范围，比如数据层、控制层、视图层、包名、文件名等等。
subject 主题描述是简短的一句话，简单说明此次提交的内容。
💡为了保证能够遵守相应的规范可以采用Commitizen 插件:
idea插件安装红色标记的任意一个 
提供了一个 commit 信息模板的输入框: 
vscode插件安装 
安装完成之后，可以通过git add添加要提交的文件，接着，在Source Control点击show git commit template图标，开始编写Commit Message信息。 
Rule 4. 【强制】分支必须有 main,dev,test 分支
分支类型
1 保护分支 不能提交操作，创世分支不能被删除
2 长期分支 不能删除
3 临时分支 短期存在，可以删除
环境类型
1 开发环境
2 测试环境
3 生产环境
| 分支类型 | 名称 | 环境类型 | 是否必须 | 命名规范 | 创建自 | 合并到 | 命名规则 | 角色 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| 保护分支 | 创世分支 | - | 是 | main | - | - | - | 项目经理 | |
| 长期分支 | 开发分支 | 开发环境 | 是 | dev | main | - | - | 项目经理 或研发人员 | |
| 临时分支 | 功能分支 | - | 否 | feature/* /* | dev | dev | 其中第一个 * 为功能描述全小写spinal-case，第二个*为根据自身团队自定义，多个用-分割。例如: feature/order-payment/23-33 | 研发人员 | |
| 临时分支 保护分支 | 集成测试分支 | 测试环境 | 是 | test/* | dev 或 tag | main 或 test 或 tag | test/版本号 默认可以不加版本号，当存在多个test分支，不加版本号默认为当前dev 迁出的test | 项目经理 | |
| 临时分支 | 修复分支 | 开发环境 | 否 | fix/* | test | test | fix/版本号 默认可以不加版本号, 规则同test | 研发人员 | |
| Tag | 生产环境 | 是 | - | main | - | tagv版本号 | 项目经理 |
分支具体描述
- main分支
创世分支在新建工程时产生.是保护分支,即不允许直接在main分支上开发,只能由别的分支合并到main.其他的所有分支都由main分支衍生,并且需要自行保证与main分支的同步
- 长期开发分支 dev
由main分支衍生，所有开发都再此分支上
- 功能分支 feature
由dev分支衍生，完成后合并到dev，并删除此分支，此分支不是必须
- 集成测试分支 test/*
是保护分支,不允许直接在集成分支上开发.是CI/CD工具主要监测的分支,每个集成测试分支对应一套集成环境,集成测试通过后,相应的代码合并到main分支,此分支来源于dev分支
- 修复分支 fix/* 当test 分支出现bug需要修复，需要建立fix分支修复完成后合并到test分支上。
流程具体描述
Rule 5. 【推荐】hotfix 修复规则
- 当某一个历史版本上发现bug,或者需要做微调时,直接从对应的tag拉出一条test分支,修订号需要增加1
- 在test分支上签出fix分支完成开发后,做test分支并在此分支上做集成测试完成后,在test分支上打tag
- 完成后可以删除此分支
- 如果该bug也影响了后续的版本,可将其视同普通的功能分支,走 dev-> test -> main -> tag流程,从而在高版本上修复bug
Rule 5. 【推荐】tag 版本号规则
以v开头并要遵循版本号规约，tag 修订版本号不为0 代表patch，如果tag经过修复修订号加1，列如：当前tag为 v2.0.0 ,修复完成后的tag为 v2.0.1
Rule 6. 【推荐】产品或项目版本号规则
产品经理定义产品或项目版本号不能使用修订号，主版本和次版本要和tag保持一致，修订号始终为0
Rule 7. 【推荐】tag 上迁出项目
在使用其它项目只能从tag上进行来取源码，步骤如下：
1.将新建项目 clone 到本地
git clone 项目git地址
2.将tag的git地址，添加至本地的remote
git remote add xx tag的git地址 xx为tag加tag版本号
3.拉去tag代码
git fetch xx tag 版本号
4.创建新分支
git checkout -b 新分支名称 tag版本号
5.推送到远程分支
git push origin -u 新分支名称
示例：
1 git clone http://ip:8929/newProject.git
2 git remote add tagv1.0.0 http://ip:8929/oldProject.git
3 git fetch tagv1.0.0 tag v1.0.0
4 git checkout -b v1.0.0-dev v1.0.0
5 git push origin -u v1.0.0-dev
Rule 8. 【强制】版本号规则
以 v 开头，主版本号.次版本号.修订号（X.Y.Z），其中 X、Y 和 Z 为非负的整数,当主版本号更新时，次版本号和修订号都要归零。次版本号更新时修订号归零
Semantic Versioning
Semantic Versioning，语义化版本号，简称“SemVer”。是一种格式化的版本号规则。并且版本号中各个部分的含义被加以了限制。这一套规则，是为了改善各种软件版本号格式混乱，语义不明的现状而提出的。
Semantic Versioning 标准的官网兼说明页面是 https://semver.org/
不需要完全按照Semantic Versioning规范执行，对其进行裁剪，以下为具体执行规范
版本规范
- v：所有版本以 v 开头。
- 语义化版本格式为：主版本号.次版本号.修订号（X.Y.Z），其中 X、Y 和 Z 为非负的整数。
- 版本号可按以下规则递增：
- 主版本号（MAJOR）：每当进行非向下兼容的修改或者颠覆性的更新时，主版本号加1
- 次版本号（MINOR）：每当进行向下兼容的修改或者添加兼容性的新功能时，次版本号加1
- 修订号（PATCH）：没有新功能的引入，仅仅是打一些兼容性补丁，做一些兼容性修复时，修订号加1。
例如，v1.2.3 是一个语义化版本号，版本号中每个数字的具体含义见下图：
当主版本号更新时，次版本号和修订号都要归零。次版本号更新时修订号归零。
如何确定版本号
1 最简单的做法是以 0.1.0 作为初始化开发版本，并在后续的每次发行时递增次版本号。
2 第一次对外发布版本号为 1.0.0
Rule 9. 【强制】maven版本后缀规范
使用以下三种分别代表不同版本，SNAPSHOT，alpha 和 release
SNAPSHOT：代表开发版本，是一种特殊的版本，代表当前开发版本，可能包含一些临时的改动。每次构建时，Maven会自动下载最新的SNAPSHOT版本
alpha：代表测试版本，通常只在开发团队内部使用
release：代表正式版本，通常是不会再进行大的改动和更新（通常正式环境后缀不需要）
| 仓库类型 | 仓库命名 | 版本后缀 | groupId | artifactId | profile |
|---|---|---|---|---|---|
| Snapshot | maven-snapshots | SNAPSHOT | com.公司英文缩写.(项目名) (示例:com.jd.hn 或 com.jg.bpm) | gitlab仓库名称 | dev 或 fix |
| Release | maven-releases | alpha或无 | 同上 | 同上 | test 或 prod |
profile配置示例如下:
<version>${env.version}</version>
<profiles>
<profile>
<id>dev</id>
<properties>
<profiles.active>dev</profiles.active>
<env.version>3.1.0-SNAPSHOT</env.version>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<env.version>3.1.0-alpha</env.version>
</properties>
</profile>
<profile>
<id>fix</id>
<properties>
<env.version>3.1.1-SNAPSHOT</env.version>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<env.version>3.1.0</env.version>
</properties>
</profile>
</profiles>Rule 10. 【强制】docker命名规范
仓库名称为gitlab项目群组名称
镜像名称为gitlab项目群组名称/gitlab仓库名称:版本号-后缀
容器名称为gitlab项目群组名称-gitlab仓库名称-环境名称
| 仓库名称 | 镜像名称 | 容器名称 |
|---|---|---|
| gitlab项目群组名称 | gitlab项目群组名称/gitlab仓库名称:版本号-后缀 (版本号-后缀 来源于maven version) | gitlab项目群组名称-gitlab仓库名称-环境名称 |
Rule 11. 【强制】docker compose命名规范
服务名使用 gitlab 仓库名称
镜像名称和容器名称和 docker 一致
网络名称使用 gitlab 仓库名称-环境名称
| docker compose 服务名 | 镜像名称 | 容器名称 | 网络名称 |
|---|---|---|---|
| gitlab仓库名称 | 同docker | 同docker | gitlab仓库名称-环境名称 |
docker compose 配置示例
version: "3.8"
services:
jm-iot-service:
image: hn-gis/jm-iot-service:3.1.0-SNAPSHOT
container_name: hn-gis-jm-iot-service-dev
ports:
- 10011:9100
restart: always
networks:
hn-gis-dev:
ipv4_address: 172.21.0.3
networks:
jm-iot-service-dev:
driver: bridge
ipam:
config:
- subnet: 172.21.0.0/24docker 镜像使用规则
1 不同项目使用某个服务，建议采用此服务tag产生的docker镜像（此镜像唯一）
2 不同项目共用同一个分支，采用分支产生的docker镜像（此镜像唯一）
3 不同项目采用不同分支，各自采用分支产生的docker镜像 (镜像为多个)
Rule 12. 【强制】jenkins 采用gitlab群组名称及结构，任务名称采用仓库名称
| 目录名称 | 任务名称 |
|---|---|
| 采用gitlab群组名称及结构 | 采用仓库名称 |
Rule 13. 【强制】部署环境规范
分：开发环境，测试环境，生产环境，公共环境，演示环境具体如下
| 环境类型 | 环境名称 | 描述 |
|---|---|---|
| 开发环境 | dev | |
| bugfix | ||
| hotfix | ||
| 测试环境 | test | |
| 生产环境 | prod | |
| 公共环境 | common | 数据库或中间件等 |
| 演示环境 | demo |
环境对应关系
示例：以版本号3.1.0为例
这里的环境是指docker环境
1 现有版本号为3.1.0，开发分支(dev) 对应环境(项目名称/服务名称:3.1.0-SNAPSHOT)，测试分支(test/3.1.0) 和测试环境(项目名称/服务名称:3.1.0-alpha),当测试完成后，产生bug需要修复时，需要建立修复分支(fix/3.1.1)在此分支上修复bug，这时候就需要增加一个开发环境(项目名称/服务名称:3.1.1-SNAPSHOT)用于修复bug的工作和联调。此环境不能影响dev分支的开发环境。当修复完成时候分支和环境可以删掉。
2 如果在3.1.0测试分支修复完成之前，tagv2.8.0版本上出现bug，这是需要从tagv2.8.0上建立测试分支(test/2.8.1)和一个测试环境(项目名称/服务名称:2.8.1-alpha)，当测试人员复现此bug后，开发人员需要建立修复分支(fix/2.8.1)，并增加开发环境(项目名称/服务名称:2.8.1-SNAPSHOT)进行修复和联调，修复后需要合并到测试分支(test/2.8.1)，测试通过后在此分支上打tagv2.8.1,（看具体情况是否决定并把测试分支(test/2.8.1)和并到main分支上，然后还需要把测试分支(test/2.8.1)合并到之前的测试分支(test/3.1.1)上）删除fix和test分支。