团队Git规范文档（操作规范及提交规范）

前言

在多人协作 的项目开发中，指定合理的或者部分强制的措施可以起到规范团队提升团队协作效率的作用。遵循良好的规范能让团队协作更加融洽，更能体现团队合作的巨 大优势，发挥出团队最强的能力。

一、操作规范

1.1 分支使用

当团队协同工作在同一个仓库里的人员较少，且并行开发的功能情况少时，可以只保留 master 和develop分支。当团队开发规模到5-10人或有大量并行的功能开发需求时，可新增feature分支开发的模式。

• master：稳定版本，主分支，一般由develop及hotfix分支合并，用于部署生产环境的分支。
• develop： 最新版本，开发分支，始终保持最新完成的代码，feature分支都是基于develop创建的
• feature: 实现新特性，特性分支，以feature/xxx 命名
• release： 发布新版本，发布分支
• hotfix： 热修复分支，修复线上bug

操作规范

1. 每开发一个新功能，创建一个feature分支，多人在此分支上开发；
2. 提测时，将master分支和需要提油的分支汇总到一个release分支，发布测试环境
3. 发现bug时，在feature分支上debug后，再次回到2
4. 发布生产环境后，将release分支合并到master分支并删除release分支；

1.2 角色说明

• owner: Git管理员（拥有者）
• Master：开发主管（管理员）
• Developer：开发人员（开发者）
• Reporter：测试人员（报告者）
• Guset：其他人员（观察者）

1.3 项目周期中的操作流程

1、创建新项目

开发主管提交代码初始版本到master，并推送至gitlab系统；开发主管在gitlab系统中设置master分支为保护分支。Protected分支不允许developer角色推送。

2、进行项目开发

开发主管在master上创建develop分支，并推送。 master分支与develop分支一样，有且仅有一个。对非并行项目可直接在develop上开发。对于多人并行开发项目，使用feature分支开发。但develop和feature开发方式不要同时使用。

3、开发新特性

每个新需求创建一个feature分支；命名： feature/XXX， 可以是需求对应版本号，也可以是特性关键字。

4、发布测试环境（release)

开发主管创建release分支，将所有要发布的分支逐个合并到release分支下（包括feature分支，多个release合并后的master分支）。 命名： release/XXX 。发布后，可删除本次已合并的所有feature分支，并通知测试。

5、修复待发布版本中的bug

开发者基于待发布的release分支，修复测试提出的bug并提交。当测试完成后，合并release分支到master和develop分支，此时master为最新代码，用作上线。

6、发布正式环境

• 开发主管将修复后的release分支与master合并后（合到release），打包发布生产环境。
• 确认发布成功后，并线上验收通过后，将release分支合并到master分支
• 在master上创建标签，命名规则：tag-日期-新特性和版本号，如：tag-20221101-商城v1.0.0 版本根据需求添加，作为发版里程碑标记
• 删除对应release分支

7、修复线上Bug（hotfix分支）

线上不同版本出现 bug时，开发主管需要完成以下任务：

• 从master分支某个tag上创建一个hotfix分支。hotfix/xxx
• 开发人员修复bug，提交到测试环境验收
• 再次发布正式环境流程后，将hotfix分支合并到master，并创建标签。命名同上。
• 删除hotfix分支

二、提交规范

提交规范这里主要指提交的commit message规范。以下是简要说明

2.1 Commit Message

基本语法： [scope]:

• type: 提交的commit类型，如feat, fix, docs
• scope: 本次commit的影响范围，可不写
• subject: 简要描述
• body: 详细描述

2.2 Type类型

• feat: 添加新特性
• fix: 修复bug
• docs: 仅仅修改了文档
• style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
• refactor: 代码重构，没有加新功能或者修复bug
• perf：增加代码进行性能测试 或性能优化
• test: 增加测试用例
• chore: 改变构建流程、或者增加依赖库、工具等
• merge: 代码合并
• revert: 回滚

2.3 相关工具

对于提交规范，有辅助性工具 Commitizen，也有强制检查工具Husky。这里主要介绍Commitzen（因为简单）
在使用commitzen进行代码提交时（git cz命令替代git commit )，它会提示你填写必需的提交字段

# 1、全局安全commitzen
npm i -g commitzen

# 2、项目中安装插件
npm i cz-customizable -D

# 3、package.json中添加配置
"config" :{
	"commitizen": {
     "path": "node_modules/cz-customizable"
   }
}

# 4、根目录添加配置文件.cz-config.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

• .cz.config.js

module.exports = {
  // 可选类型
  types: [
    { value: 'feat', name: 'feat:     新功能' },
    { value: 'fix', name: 'fix:      修复' },
    { value: 'docs', name: 'docs:     文档变更' },
    { value: 'style', name: 'style:    代码格式(不影响代码运行的变动)' },
    {
      value: 'refactor',
      name: 'refactor: 重构(既不是增加feature，也不是修复bug)'
    },
    { value: 'perf', name: 'perf:     性能优化' },
    { value: 'test', name: 'test:     增加测试' },
    { value: 'chore', name: 'chore:    构建过程或辅助工具的变动' },
    { value: 'revert', name: 'revert:   回退' },
    { value: 'build', name: 'build:    打包' }
  ],
  // 消息步骤
  messages: {
    type: '请选择提交类型:',
    customScope: '请输入修改范围(可选):',
    subject: '请简要描述提交(必填):',
    body: '请输入详细描述(可选):',
    footer: '请输入要关闭的issue(可选):',
    confirmCommit: '确认使用以上信息提交？(y/n/e/h)'
  },
  // 跳过问题
  skipQuestions: ['body', 'footer']
  subjectLimit: 72  // subject文字长度默认是72
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

最后，在提交时，使用git cz代替git commit -m