Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "Git specification operation case analysis". In the operation process of actual cases, many people will encounter such a dilemma, 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!

Specification

Git commit message is the history of code submission, and incorrect submission information will affect the maintainability of the code. In a multi-person collaborative development scenario, due to different personal styles, it is easy to lead to confusion if there is no unified specification. At present, the specification is mostly used by the Angular team.

Message submission format

Each submission message contains a header, body, and footer. Header has a special format, including type,scope and subject:

():

To make it easier to read in various git tools, any line of the submitted message cannot exceed 100 characters.

Header

Type

Must start with one of the following:

Feat: a new feature feature

Fix: bug repair

Docs: only documents have been modified

Style: no code changes, style adjustments (white space, formatting, missing semicolons, etc.)

Refactor: code refactoring that neither fixes bug nor adds feature changes

Perf: code changes to improve performance

Test: add missing or correct existing tests

Build: changes that affect the build system or external dependencies, such as gulp, broccoli, npm

Ci: changes to CI configuration files and scripts, such as Travis,Circle,BrowserStack,SauceLabs

Chore: change the build process or aids and libraries, such as document generation, etc.

Revert: if the submission restores the previous submission, it should start with revert:, followed by the header of reverted commit. In addition, This reverts commit should be marked in the body, where hash is the SHA value of the submission to be restored.

Scope

Scope is optional.

Used to assist in indicating the attribution of the code changes to be committed, such as indicating which location (location), which module (module), which component (componet), and so on. You can use * when the change affects more than one range.

Subject

This topic contains a concise description of the change:

Use the present tense: "change" is neither "changed" nor "changes"

Don't capitalize the first letter.

There is no click at the end. )

Body

As in the subject, use the imperative present tense: "change" instead of "changed" or "changes". Body should include motivation for change and compare it with previous behavior.

Footer

Incompatible changes

If the current code is not compatible with the previous version, the Footer section starts with BREAKING CHANGE, with a space or two newline characters, followed by a description of the change, the reason for the change, and the migration method. Such as fix and carry BREAKING CHANGE information:

Fix: correct spelling of referrer in headerBREAKING CHANGE: Rather than using misspelled "Referer" as name of header,instead use correct spelling "Referrer". Clients expecting "Referer" will nolonger receive that header and will presumably not honor the new "Referrer" until updated to support this new name for this header.

Close Issue

If the current commit is for an issue, you can close the associated issue in the Footer section.

Closes # 123

Or close multiple issue

Closes # 123 # 456 # 789 Project configuration

The more popular solution now is the negotiated submission Specification (Conventional Commits), which is inspired by and largely based on the Angular submission principle. The author tries to find Git normalization aids or plug-ins based on non-node environment, but does not find a good solution, but if we have a node environment, non-node projects can be configured and executed normally, but in the project will generate node project-related files, such as node_modules folders, package.json files, etc., so there is a little trouble in the version control of the project, and define our own ingore files as needed. Solve the problem of project code and environment code.

Environment and tools

Node

Npm (npx)

Commitizen/cz-cli: a tool for formatting commit message that binds submitters to fill in commit message step by step according to established specifications.

Cz-conventional-changelog: specify an Adapter for commitizen, a preset that conforms to the Angular team specification (help us generate commit message according to the specification we specified)

Non-node project

Navigate to the workspace directory (that is, the project root directory) and enter npm init on the command line, and a series of initialization reminders will appear after execution, and you can enter until the end.

Dependent installation

Install commitizen and cz-conventional-changelog

Npm I-D commitizennpm i-D cz-conventional-changelog

Modify the package.json file

Configuration example of the project. PNG

{"name": "testp", "version": "1.0.0", "description": "", "main": "index.js", "scripts": {"test": "echo\" Error: no test specified\ "& exit 1", "commit": "git-cz"} "config": {"commitizen": {"path": "node_modules/cz-conventional-changelog"}, "author": "," license ":" ISC "," devDependencies ": {" commitizen ":" ^ 4.2.3 "," cz-conventional-changelog ":" ^ 3.3.0 "}}

In the root directory of the project, execute npm run commit on the command line, and a reminder will appear to fill in the standardized information as mentioned above.

Operation reminder. Png

Operation reminder.. png

After execution, sourcetree effect picture:

Effect diagram .png

Commit message checksum blocking

Although we have configured commit in the project, if I perform the standard operation, do not use npm run commit to submit code, and directly commit through the command line or Git visualization tool, then the submitted information may be non-standard, so we need to block the git command and lint the message content.

Lint tools depend on installation

Commitlint/cli [command line tool]

Commitlint/config-conventional [Verification rules] conforms to the Angular team specification.

Npm I-D @ commitlint/config-conventional @ commitlint/cli

Modify package.json and configure commitlint

{... "scripts": {"test": "echo\" Error: no test specified\ "& & exit 1", "commit": "git-cz", "commit-lint": "commitlint-e $HUSKY_GIT_PARAMS"}, "config": {"commitizen": {"path": "node_modules/cz-conventional-changelog"}} "commitlint": {"extends": ["@ commitlint/config-conventional"]},...}

Install Husky for git hooks verification

Npm install husky-save-dev

Enable git hooks

Npx husky install

When git hooks is enabled, .husky folders are produced under the root of the project.

I

Add commit_msg to husky to block git commit commands

Npx husky add. Husky/commit-msg "npm run commit-lint"

A script for commit-msg will be generated after execution is completed.

Commit-msg-shell.png

At this point, if we execute git commit-m "test message" directly on the command line, we will be prevented from submitting the reminder to fail.

Image.png

The problem with SourceTree

If you submit the code with SourceTree after the above configuration is complete, you will find a running error.

Image.png

This is because SourceTree does not read the environment variable information, so you need to add the configuration of the environment variable to the commit-msg script.

Image.png

#! / bin/sh. "$(dirname" $0 ") / _ / husky.sh" export PATH=/usr/local/bin:$PATHnpm run commit-lint-silent

Running again now, it has been successfully blocked.

Description

Both the cz-conventional-changelog submission reminder and the @ commitlint/config-conventionallint rule can set their own Adapter, and you can configure the specification that suits your team according to your needs.

The screenshot of the article is configured from the perspective of non-node (Android) projects, and other projects are similar. As long as you use Git for version control, you can achieve the standardized verification of Commit Message.

The article relies on the similarity under Mac OS,Windows, and all dependent libraries can also work under Windows, but the configuration of the environment is different.

This is the end of the content of "Git specification operation example analysis". 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.