Links to other specifications

RESTful Interface specifications

CSS specifications and naming

JavaScript specification and naming

1. Branch naming and protection

1.1 Branch Naming

1.1.1 Master (Master Branch)

  • Main branch, online environment
  • This branch is a read-only branch and can only be accessed fromtestBranch merge. You cannot make changes directly on this branch
  • All inmasterBranch push should be labeled and recorded for easy traceability

1.1.2 Release (Pre-release branch)

  • Pre-release branch, based ondevBranch of cloning
  • When a set of features is developed, it will be merged into dev branch first, and release branch will be created based on dev branch for testing
  • If there are bugs that need to be fixed during the testing process, they are directly fixed and submitted by the developer in the Release branch and merged into the dev branch after the fixes are completed

1.1.3 DEV (Main Development Branch)

  • Main development branch, based onmasterBranch of cloning
  • This branch is read-only and can only be accessed from other branches (feature/hotfix) merge, cannot be modified directly on this branch
  • Contains all to publish to the nexttestBranch code
  • When the development of feature function branch is completed, merge intodevbranch

1.1.4 Feature (Feature Development Branch)

  • Functional development branch, based ondevBranch of cloning
  • When developing new features, you need to start fromdevBranch pullfeatureBranch, branch named feature- feature name/module name
  • When the development is complete, merge the code intodevBranch and delete the branch

1.1.5 HotFix (Bug Fix Branch)

  • Patch branch, based onmasterBranch cloning is mainly used to fix bugs in the online version
  • Name it hotfix-bug module name and merge it intodevbranch
  • It is a temporary branch and can be deleted after patch repair goes online

1.2 Branch Protection

The master branch, test branch, and dev branch can only be merged through merge Request.

The responsible person will conduct code review and then merge into the corresponding branch.

2. Commit Message specification

Refer to the basic commit format Angular defines

Reference documentation

Concrete example

2.1 Basic Format

The basic format is as follows:

<type>(<scope>) :<subject>
 
<body>
 
<footer>
Copy the code

The Header part of the first line is mandatory, and the Body and Footer parts are optional. Notice that Header, Body, and Footer are separated by blank lines.

2.2 the Header

The Header section is a single line with three fields: Type (required), scope(optional), and subject(required).

Type:

Type indicates the type of commit. Only the following seven identifiers are allowed

  • feat: New feature
  • fix: fixing bugs
  • docs: Documentation
  • style: format (changes that do not affect code execution)
  • refactor: Refactoring (not new features, not code changes to fix bugs)
  • test: Add tests
  • chore: Changes to the build process or ancillary tools

Normally feat and fix are stored in changelog (changelog), but other types are not.

Scope:

Scope indicates the scope of the commit impact. This value is optional. Usually files, paths, functions, etc

Subject:

Subject is a short description of the commit purpose. It is usually in English and contains no more than 50 characters

  • Start with a verb and use the first person present tense, as inchangeRather thanchanged 或 changes
  • The first letter is lowercase
  • Ending without a period (.)

2.3 the Body

The Body section is an optional, detailed description of the commit and can be broken into multiple lines (wrap with \n), as shown in this example:

More detailed explanatory text, if necessary. 
Further paragraphs come after blank lines. 

- Bullet points are okay, too 
- Use a hanging indent
Copy the code

2.4 the Footer

The Footer section is only used in two cases:

Incompatible changes

If the current code is incompatible with the previous version, the Footer section begins with BREAKING CHANGE, followed by a description of the CHANGE, the reason for the CHANGE, and the migration method.

Closed questions

If the current COMMIT is for a problem, you can turn it off in the Footer section:

Closes #234
Copy the code

You can also close more than one problem at a time:

Closes #123, #245, #992
Copy the code

3. Automate tool processing commit message

As the Commit Message rule shows, if it is obvious that writing the basic commit format above is inconvenient and error prone, you can use an automated tool to generate a Commit message from the specification above.

3.1 Commitizen

You can normalize git commit messages using the Commitizen tool.

Commitizen is essentially a generic framework for standardizing Git commit specifications. You can format git commit Adapters using various Adapters. The rule we used above is the Angular COMMIT format, so you need to install an additional Adapter, CZ-Xconventional – Changelog. Commitizen adaptors include Angular, ESlint, Mapbox, Jira, etc. We only use CZ-Xconventional – Changelog to implement Angular commit format.

3.2 Usage

Install Commitizen globally

npm install commitizen -g
Copy the code

Initialize the current project with the commitizen command

commitizen init cz-conventional-changelog --save-dev
Copy the code

After the command is executed, the FOLLOWING configuration section is added in the devDependencies configuration of CZ-Conventional – Changelog in package.json file

"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"}}Copy the code

In this case, use git cz instead of git commit.

4. Git hook set commit message verification

You can add commitLint validation to git commit hooks to prevent local commits that do not comply with the commit specification.

4.1 Usage

Install husky, Commitlint dependencies in your project

npm install husky @commitlint/config-conventional @commitlint/cli --save-dev
Copy the code

Add husky’s Git hook configuration to package.json file

{
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -x @commitlint/config-conventional -E HUSKY_GIT_PARAMS"}}}Copy the code

At this point, the hook will report an error if a commit message is submitted that does not conform to the specification.

4.2 Configuration Rules

We can configure custom rules by generating commitlint.config.js or.commitlintrc.js files:

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
Copy the code

The configuration of the commitlint.config.js file is as follows:

module.exports = {
  extends: [
    "@commitlint/config-conventional"].rules: {
    'type-enum': [2.'always'['upd'.'feat'.'fix'.'refactor'.'docs'.'chore'.'style'.'revert'
     ]],
    'type-case': [0].'type-empty': [0].'scope-empty': [0].'scope-case': [0].'subject-full-stop': [0.'never'].'subject-case': [0.'never'].'header-max-length': [0.'always'.72]}}Copy the code

Rules consists of name and configuration arrays. For example, “‘name’: [0, ‘always’, 72]”, the first digit in the array is level. 0, 1, 2, 0 is disable, 1 is warning, 2 is error. The second value is application or not. The value can be always or never. The third bit is the value of the rule.

For more configuration rules, see the CommitLint official website: CommitLint Rules

Git hook esLint verification and repair

Lint-staged validations can also be added to git commit hooks to perform Lint fixes on Temporized Git files.

5.1 Usage

Install HusKY, Lint-Staged, and ESLint dependencies

npm install husky lint-staged eslint --save-dev
Copy the code

Add husky and Lint-staged configurations to package.json files

"husky": {"hooks": {
    "pre-commit": "lint-staged"}},"lint-staged": {
  "src/**": [
    "eslint --fix"]}Copy the code

5.2 Configuration Rules

The above lint fixes follow the configuration in the.eslintrc.js file.

Eslint Configuration rules see: ESLint