When I wrote my own code, whenever I needed to submit the code to GitHub, I would directly git commit ‘XXXX’, and then push it directly. Later, the project became a little too big, and some other friends joined in the development of the project, and they submitted the code to my project repository. It’s embarrassing to look at their submission after a long time and not even know what they did. So git submitted must be the standard, especially in the collaboration project, if git submit accurate, late late in collaboration, and review will be documented, the project of development can be illustrated according to the specification submitted quickly generate log, convenient to a developer or user to track project information and features.
commit message
Every time we commit, we have to do something special, build a new feature, fix a bug, etc. We have the following categories for different operations:
-
Type: Indicates the type of the commit
-
Feat: Develop new functions
-
Fix: fix the bug
-
Refactor: Code refactoring
-
Docs: Document modification
-
Style: Code format modification, note not CSS modification
-
Test: Test case modification
-
Perf: Improves performance
-
Build: Change project builds or external dependencies (e.g. scopes: webpack, gulp, NPM, etc.)
-
Chore: Other modifications, such as build process, dependency management.
-
Revert: Code rollback
The commit format is also standard:
-
Scope: commit Specifies the scope of the impact, for example: route, Component, utils, build…
-
Subject: Overview of commit
-
Body: commit Specifies the modification
-
Footer: Some notes, usually a link to BREAKING CHANGE or bug fixes.
AngularJS submission specification
Angular’s submission specification is currently the most recognized and popular in the industry, and we use Commitizen and CZ-Customizable to implement the submission specification. These two tools can automatically generate submission information based on your choice, and then submit happily. Install Commitizen and CZ-CustomIZABLE:
npm install -D commitizen
npm install -D cz-customizable
Copy the codeConfigure the config.commitizen field in package.json to configure the adapter path for the CZ tool:
"config": {
"commitizen": {
"path": "node_modules/cz-customizable"
}
}
Copy the codeCreate.cz-config.js in the project root directory:
'use strict'
module.exports = {
types: [
{
value: 'feat ✨'
name: '✨ feat: A new feature'
},
{
value: 'fix 🐞'.
name: '🐞 fix: A bug fix'
},
{
value: 'the refactor 🛠'.
name:
'🛠 refactor: A code change that neither fixes A bug nor adds A feature'
},
{
value: 'docs 📚'.
name: '📚 docs: Documentation only changes'
},
{
value: 'the test 🏁'.
name: '🏁 test: Add missing tests or existing tests'
},
{
value: 'chore 🗯'.
name:
"🗯 chore: Changes that don't modify SRC or test files. Such as updating build tasks, package Manager"
},
{
value: 'style 💅'.
name:
'💅 style: Code Style, Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)'
},
{
value: 'revert ⏪'.
name: '⏪ Revert: Revert to a commit'
}
].
scopes: [].
allowCustomScopes: true.
allowBreakingChanges: ['feat'.'fix']
}
Copy the codeChinese version:
module.exports = {
types: [
{ value: 'feat ✨'.name: 'Features: A new feature' },
{ value: 'fix 🐞'.name: 'Fix: Fix a Bug' },
{ value: 'docs 📚'.name: 'Documentation: Only documentation changes' },
{ value: 'style 💅'.name: 'Formatting: Spaces, semicolons and other formatting fixes' },
{ value: 'the refactor 🛠'.name: 'Refactoring: Code refactoring, separate from features and fixes' },
{ value: 'the perf 🐎'.name: 'Performance: Improve performance' },
{ value: 'the test 🏁'.name: 'Tests: Add a test' },
{ value: 'revert ⏪'.name: 'Rollback: Code rollback' },
{ value: 'chore 🗯'.name: 'Tools: Development tool changes (build, scaffolding tools, etc.)' }
].
messages: {
type: 'Choose one of your submission types :'.
customScope: 'Please enter modification scope (optional):'.
subject: 'Short description :'.
body: 'long, the use of "|" newline (optional) :'.
footer: 'Associated closed issues, e.g. #31, #34(optional):'.
confirmCommit: 'Sure about the submission instructions? '
},
allowCustomScopes: true.
allowBreakingChanges: ['properties'.'repair'].
subjectLimit: 100
}
Copy the codeGit CZ can then be used to commit. Let’s optimize it again. Let’s configure the script command in script:
"scripts": {
"commit": "git-cz"
}
Copy the codeAt this point we are happy to commit using NPM Run Commit.
Continue to optimize
Suppose there are two programmers. One day, Programmer A develops a new feature and happily submits it using the above steps. A few days later, programmer B changes the code on his basis and submits it again. Then this function module can only be iteratively maintained by the program monkey A. So on a beautiful Monday morning, the programmer opens vscode, pulls the project code, and tries to have fun developing it, but finds that his original code has been changed beyond recognition: “I didn’t have a semicolon here…” “, “There used to be double quotation marks…” . He was immersed in thinking about life. From the short story above, we learned that in team development, the code becomes more and more difficult to maintain because everyone’s code is different and a thousand Hamlets come out. So we need some “rules” to discipline team members and achieve a consistent style. Here is a set of “dragon eighteen palms” :
eslint
Eslint: provides the code specification, provides an automatic code verification program, and prints the verification results: tells you which file which line of code does not conform to which code specification, so that you can modify the code, which can be configured through the configuration file. Such as:
//.eslintrc.js
{
"extends": ["airbnb"."plugin:prettier/recommended"].// ESLint extends rules
"parserOptions": {
"ecmaVersion": 7.
"sourceType": "module".
"ecmaFeatures": {
"jsx": true
}
},
"parser": "babel-eslint".// Resolve THE ES6 improt error
"env": { // eg If browser is not configured, esLint will report undefined
"es6": true.
"browser": true.
"node": true
},
"plugins": ["react"."jsx-a11y"."import"].
"rules": {
"class-methods-use-this": 0.
"import/no-named-as-default": 0.
"react/jsx-filename-extension": [
"error".
{
"extensions": [".js".".jsx"]
}
]
}
}
Copy the codeIn ESLint, you can restrict the number of lines in a file, the length of a single line of code, even the complexity of functions, and so on.
prettier
NPM install -d prettier prettier NPM install -d prettier prettier Prettier allows uniform code formatting. There was no longer a semicolon dispute. Such as:
//.prettierrc
{
"printWidth": 120.// The maximum number of characters in a line
"tabWidth": 2.// The number of characters occupied by TAB
"useTabs": false.// Whether to use TAB instead of space
"semi": true.// Use a semicolon after each sentence
"singleQuote": true.// Whether to use single quotation marks
"jsxSingleQuote": false.// Whether JSX uses single quotes
"trailingComma": "all".// End of array comma.
"bracketSpacing": false.// {foo: xx}还是{ foo: xx }
"arrowParens": "always" // Whether the arrow header function argument uses ()
}
Copy the codeWith the above two methods, we have been able to achieve a good code format unification, but a new problem arises: when to develop the code rule verification and formatting unification? I believe many of you have come up with a solution: checksum formatting at commit time.
Husky husky: Husky is an NPM package that makes it easy to configure git hook scripts in package.json. We’ll use one main hook here :pre-commit, which will perform the action you want when you commit. Such as:
"husky": {
"hooks": {
"pre-commit": "npm run lint"
}
Copy the codeNPM run Lint, a hook script, will be executed before each git commit. So we put the esLint and prettier operations inside the pre-commit hook:
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{json,css,md}": [
"npm run format".
"git add"
].
"*.scss": [
"npm run lint:scss".
"npm run format".
"git add"
].
"*.{js,vue,ts,tsx}": [
"npm run lint".
"npm run format".
"git add"
]
}
Copy the codeAs mentioned, esLint’s rule validation and prettier formatting were done before every commit. But there is one problem that remains unsolved. Let me elaborate. Now let’s go back to the root of our project and use git add. Git commit -m XXX/NPM run commit/git commit/NPM run commit/git commit/git commit/git commit/git commit/git commit/git commit/git commit/git commit/git commit/git commit/git commit/git commit/git commit/git commit I mean we should verify the commit, and if the check fails, we don’t allow the commit. So let’s keep going.
Commitlint and commitlint – config – cz
Install commitlint and commitlint-config-cz:
npm install -D @commitlint/cli
npm install -D commitlint-config-cz
Copy the codeCreate a new commitlint.config.js file in the root directory of the project:
module.exports = {
extends: [
'cz'
].
rules: {
'type-empty': [2.'never'].// It is not allowed to submit a null type
'subject-empty': [2.'never'] // The submitted content is not allowed to be empty
}
}
Copy the code "husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS".// Add this sentence to the husky configuration, meaning to verify before committing
"pre-commit": "lint-staged"
}
}
Copy the codeGit comiit -m XXX = git comiit -m XXX = git comiit -m XXX At this point we complete the specification of the front-end submission code ~
conclusion
Let’s start with a flow chart of the submission:
Through Commitizen, CZ-CustomIZABLE, ESLint, Prettier, Husky, commitLint we completely bound the submission process to ensure code uniformity and improve code robustness and maintainability. Saved a lot of time for the later work, and can save a lot of time to hook up with a little sister 😏