Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "introduction to the principles of Git commit message and Workflow Specification". Many people will encounter such a dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Purpose

Unifies the team Git commit log standard, facilitates the subsequent code review, the version release and the log automatic generation and so on.

Unified team's Git workflow, including branch usage, tag specification, issue, etc.

Git commit Log reference case

Angular

Commit-message-test-project

Babel-plugin-istanbul

Conventional-changelog

Overall plan

Basic specification for Git commit logs ():

The description of the format is as follows:

Type represents the type of commit, such as whether to fix a bug or add a new feature. All type types are as follows:

Feat: new feature

Fix: repairing bug

Docs: only modified the document, such as README, CHANGELOG, CONTRIBUTE, etc.

Style: just change the space, format indentation, all good, etc., do not change the code logic

Refactor: code refactoring without adding new features or fixing bug

Perf: optimization related, such as improving performance and experience

Test: test cases, including unit tests, integration tests, etc.

Chore: change the build process, or add dependent libraries, tools, etc.

Revert: rollback to the previous version

Format requirements:

# title line: within 50 characters, describe the main changes # # body content: more detailed description text, less than 72 characters is recommended. The information to be described includes: # # * Why is this change necessary? It may be used to fix a bug, add a feature, improve performance, reliability, stability, etc. # * how does he solve this problem? Specifically describe the steps to solve the problem # * are there any side effects and risks? # tail: if you need to change, you can add a link to an issue address or other document, or close an issue. Git Branch and release Specification

Basic principle: master protects the branch and does not modify and commit code directly on the master.

When developing daily requirements or projects, checkout a feature branch on the master branch for development or bugfix branch for bug repair. After functional testing is completed and the project is released, merge the feature branch into the backbone master, and release it with Tag, and finally delete the development branch. Branch naming convention:

Branch version naming rules: branch type _ branch release time _ branch function. For example: feature_20170401_fairy_flower

Branch types include: feature, bugfix and refactor, namely, new feature development, bug repair and code refactoring.

Time is named with year, month and day, with less than 2 digits to make up 0

Branch function naming uses the snake case nomenclature, that is, underscore naming.

Tag includes a 3-bit version with a v prefix. Such as v1.2.31. Tag naming convention:

V2.0.0-alpha-1

V2.0.0-belta-1

The second version number is used for new feature development, and the third version number is used for bug repair.

The core base library or Node intermediate price can be released in a large version. Please use the grayscale version number, suffix the version and separate it with an underscore. Alpha or belta is followed by the number of times, that is, the number of alpha:

Changelog documents need to be generated before the official release of the version, and then released online.

How do I access it?

Connect to the reference commit-message-test-project project. The specific steps are as follows:

Step 1: add the scripts and dependencies content shown in the following code to the package.json file under the project and directory, and the version number is 3-digit version number.

{"name": "application-name", "version": "0.1.0", "scripts": {"commitmsg": "validate-commit-msg", "commit": "git-cz", "changelog": "conventional-changelog-p angular-I CHANGELOG.md-s-r 0"}, "devDependencies": {"commitizen": "^ 2.3.0" "validate-commit-msg": "^ 2.11.1", "conventional-changelog-cli": "^ 1.2.0", "husky": "^ 0.13.1"}}

Step 2: create a new .vcmrc file in the root directory of the project, and the file content is

{"helpMessage": "\ nPlease fix your commit message (and consider using https://www.npmjs.com/package/commitizen)\n"," types ": [" feat "," fix "," docs "," style "," refactor "," perf "," test "," chore "," revert "]," warnOnFail ": false," autoFix ": false} Git commit operation flow after connection

Step 1: create a feature branch or bugfix branch

Sh $git checkout-b feature_infinite_load # switch to a feature branch or bug fix branch sh

Step 2: submit the code to the local Git repository and fill in the Commit message format that meets the requirements

$git add. $git commit # do not add any parameters here, such as-m

As shown in the following figure:

Step 3: synchronize the code to the remote Git repository

$git push origin feature_infinite_load # publish the changes to the remote repository

Step 4: generate changelog automatically and release it by typing Tag

Tnpm run changelog # uses the changlog command in npm script to generate logs directly from the git metadata. This is the end of $git tag v0.1.0$ git push origin v0.1.0 "introduction to Git commit message and Workflow Specification". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.