git workflow and git commit specification

Purpose

Unify the Git workflow of the team, including branch usage, tag specification, issue, etc.
Unify the team's Git Commit log standard, which is convenient for subsequent code review, version release and automatic log generation

git workflow

git flow workflow:
- master is the main branch, which is a protected branch, and code modification and submission cannot be performed directly here.
- develop is a branch for daily use.
- The new feature branch of feature, when a feature is completed and the test is passed, it is merged into the develop branch.
- The hotfix online emergency vulnerability repair branch is pulled and created from the master branch, and merged into the master and develop branches after fixing bugs.
gitlab flow workflow (the biggest principle is called "upstream first" (upsteam first), that is, there is only one main branch master, which is the "upstream" of all other branches. Only the code changes adopted by the upstream branch can be applied to other branches):

master->pre-production->production

master development environment branch
pre-production environment branch
production branch

git commit specification

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
复制代码

占位标签解析：
type:代表某次提交的类型，比如是修复一个bug还是增加一个新的feature。所有的type类型如下：
scope:scope说明commit影响的范围。scope依据项目而定，
		例如在业务项目中可以依据菜单或者功能模块划分，
		如果是组件库开发，则可以依据组件划分。
subject:是commit的简短描述
body:提交代码的详细描述
footer:如果代码的提交是不兼容变更或关闭缺陷，则Footer必需，否则可以省略。

feat[特性]:新增feature 
fix[修复]: 修复bug     
docs[文档]: 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等
style[格式]: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor[重构]: 代码重构，没有加新功能或者修复bug
perf[优化]: 优化相关，比如提升性能、体验
test[测试]: 测试用例，包括单元测试、集成测试等
chore[工具]: 改变构建流程、或者增加依赖库、工具等
revert[回滚]: 回滚到上一个版本
复制代码

Example:

特性:添加头像功能
特性:添加收藏功能
修复:在android机器上传崩溃问题解决
文档:修改README,增加了使用说明
优化:首页图片加载缓慢优化
重构:对头像功能进行封装重构
复制代码

Git tag packaging specification

**Tag version number: **Tag includes a 3-digit version, prefixed with v. Such as v1.2.31.
Tag naming conventions:
1. The second-digit version number is used for new function development, and the third-digit version number is used for bug fixes.
2. The first version number is a brand-new function class, and the adjustment is made only after the function module goes online.

**Title format: project name-date
Content format: <category>---<content>
<category>:**New features, bug fixes, optimizations, dependency upgrades, refactorings, bugs & patches

Example:

This image is quoted from: Our GIT Workflow

Git Commit format check

Prepare commitlint/cli for format validation
Trigger verification when preparing husky for git commit code

Install commitlint/cli globally

npm install -g @commitlint/cli @commitlint/config-conventional
复制代码

2. Create a configuration file commitlint.config.js in the project root directory, you can use the following command to create

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
复制代码

3. Define the submission specification in the configuration file, you can use the following configuration:

"module.exports = {extends: ['@commitlint/config-conventional']}"

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', [
      "feat", "fix", "docs", "style", "refactor", "test", "chore", "revert"
    ]],
    'subject-full-stop': [0, 'never'],
    'subject-case': [0, 'never']
  }
};
复制代码

4. Add husky to the project, and perform git submission trigger verification. The installation is as follows:

npm install husky --save-dev
复制代码

5. After the installation is complete, configure the following information in package.json

"scripts": {
    "commitmsg": "commitlint -e $GIT_PARAMS",
 },
 "config": {
    "commitizen": {
      "path": "cz-customizable"
    }
 },
复制代码

6. After the above steps, the specification verification of git commit has been completed. Code submission is ready.

不规范提交>git commit -m "添加新功能"
提示：
⧗   input: 添加新功能
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

规范提交>git commit -m "feat: 添加新功能"
复制代码

Sinicization and custom verification rules

1. The current project installs commitlint-config-cz, as follows

npm install commitlint-config-cz --save-dev
复制代码

2. Add the following settings to the commitlint validation rule configuration:

module.exports = {
  extends: [
    'cz'
  ]
};
复制代码

3. Download the official configuration file for modification. The official configuration file cz-config-EXAMPLE.js . The modified example is as follows:

'use strict';

module.exports = {

  types: [
    {value: '特性',name: '特性:    一个新的特性'},
    {value: '修复',name: '修复:    修复一个Bug'},
    {value: '文档',name: '文档:    变更的只有文档'},
    {value: '格式',name: '格式:    空格, 分号等格式修复'},
    {value: '重构',name: '重构:    代码重构，注意和特性、修复区分开'},
    {value: '性能',name: '性能:    提升性能'},
    {value: '测试',name: '测试:    添加一个测试'},
    {value: '工具',name: '工具:    开发工具变动(构建、脚手架工具等)'},
    {value: '回滚',name: '回滚:    代码回退'}
  ],

  scopes: [
    {name: '用户模块'},
    {name: '订单模块'},
    {name: '社区模块'},
    {name: '商品模块'}
  ],

  // it needs to match the value for field type. Eg.: 'fix'
  /*
  scopeOverrides: {
    fix: [
      {name: 'merge'},
      {name: 'style'},
      {name: 'e2eTest'},
      {name: 'unitTest'}
    ]
  },
  */
  // override the messages, defaults are as follows
  messages: {
    type: '选择一种你的提交类型:',
    scope: '选择一个scope (可选):',
    // used if allowCustomScopes is true
    customScope: 'Denote the SCOPE of this change:',
    subject: '简要说明:\n',
    body: '详细说明，使用"|"换行(可选)：\n',
    breaking: '非兼容性说明 (可选):\n',
    footer: '关联关闭的issue，例如：#31, #34(可选):\n',
    confirmCommit: '确定提交?'
  },

  allowCustomScopes: true,
  allowBreakingChanges: ['特性', '修复'],

  // limit subject length
  subjectLimit: 100

};
复制代码

generate changelog

1. Install conventional-changelog, which can quickly generate commit logs

npm install -g conventional-changelog-cli
npm install -g cz-conventional-changelog
复制代码

.czrc 2. Add a configuration file to the project root directory , the content of the file is as follows

{ "path": "cz-conventional-changelog" }
复制代码

3. Add the following instructions to the scripts item in package.json

"version": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md"
复制代码

4. Execute npm run version to generate the changelog log in the current directory.

Reference: Introduction to the use of
our GIT workflow
Cz toolset - Specification of Git commits
git workflow

Reprinted in: https://juejin.im/post/5d05ef596fb9a07ef63fdbe7