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

This article introduces the relevant knowledge of "standardizing GIT code submission information and automatic version management". In the operation 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!

Preface

Git as an indispensable tool for developers, code submission is also a very frequent daily operation, if you or your team do not currently have a specification or constraint on submitting information, then you need to take a look at the content of this article.

Why standardize the submission of information

First of all, it must be necessary to standardize the submission of information, and briefly summarize the following benefits:

Let the maintenance or users of the project know what changes have been submitted

A clear historical record. You may need to find it one day.

Canonical submission records can be used to automatically generate modification logs (CHANGELOG.MD)

Trigger the build and deployment process based on the submission type

What specifications are used?

Conventional Commits (engagement submission specification) is the most widely used submission information specification at present, which is mainly inspired by the AngularJS specification. The following is a structure of specification information:

[optional scope]: / / empty line [optional body] / / empty line [optional footer (s)] specification

The category submitted by type must be one of the following types

Feat: add a new feature fix: fix bugdocs: only modify the document style: make changes that do not affect the meaning of the code, spaces, formatting, lack of semicolons, etc. Refactor: code refactoring, neither fixing bug, nor modifying new features perf: code to improve performance test: add tests or update existing test chore: build or accessibility or dependent library updates

Scope is optional, indicating the scope, function, and module of influence

Subject is required, simple description, no more than 50 words

Optional body to fill in a more detailed description

Footer is optional, which is used to fill in associated issus, or BREAK CHANGE

BREAKING CHANGE

Must be uppercase, indicating that a destructive API change has been introduced, usually a large version of the change, BREAKING CHANGE: must then provide a description, the following is an example of a commit that contains a destructive change

Feat: allow provided config object to extend other configsBREAKING CHANGE: `extends` key in config file is now used for extending other config files

For more detailed instructions, please see the contractual submission specification.

How to constrain specifications

How to ensure that each submission complies with the specification? the best way is to generate and verify it through tools. Commitizen is a nodejs command line tool that interactively generates git commit that conforms to the specification. The interface is as follows:

Start the installation:

# install npm install-g commitizen# globally or install $npm install locally-- save-dev commitizen# install adapter npm install cz-conventional-changelog

Packages.json specifies which specification to use in the configuration file

... "config": {"commitizen": {"path": "cz-conventional-changelog"}}

After installation, you can use git cz instead of git commit, and then follow the prompts to enter it step by step

Format check commitlint

Maybe you don't want to generate it through the interactive interface every time, or you still want to use git commit-m 'message',. Then in order to ensure the correctness of the information, you can use husky to verify the format of the submitted information.

Installation dependency

Npm install-- save-dev @ commitlint/ {config-conventional,cli} # install huskynpm install-- save-dev husky

Add a commitlint.config.js file to the project

Echo "module.exports = {extends: ['@ commitlint/config-conventional']}" > roomlint.config.js````package.json` configuration # git submission verification "husky": {"hooks": {"commit-msg": "commitlint-E HUSKY_GIT_PARAMS"}}

OK is done at this point. Finally, add a commitizen-friendly logo to your project README.MD.

[! [Commitizen friendly] (https://img.shields.io/badge/commitizen-friendly-brightgreen.svg) _ blank] (http://commitizen.github.io/cz-cli/)## automatic version management and generating CHANGELOG normalized submission information not only can well describe the modification of the project, but also has a good function of generating CHANGELOG.MD and automatically generating version numbers according to the submission record. # standard-version A command line tool used to generate `CHANGELOG.md` and distribute `CHANGELOG.md`: * automatically modify the latest version number, which can be `package.json` or customize a file * read the latest version number and create an updated `CHANGELOG.md` * based on the submission information Generate `CHANGELOG.md` * create a new submission including `CHANGELOG.md` and `package.json` # semantic version control (SemVer) first simply understand what semantic version control is, which is a rule initiated by `GitHub` to regulate the increment of version numbers. The second edition number. The rules for increasing the revision number and version number are as follows: * Major version number (major): when you make incompatible API modifications, * minor version number (minor): when you make downward compatible functional additions, it can be understood as Feature version, * revision number (patch): when you make a downward compatible problem correction, it can be understood as Bug fix version. The advance version number can be added to the major version number. minor version number. after the revision number, as an extension. # the advance version will be released immediately before the major version is changed, but there is no guarantee that the function of this version will be 100% normal. At this time, you can release the advance version: * alpha: internal version * beta: public beta version * rc: candidate version (Release candiate), for example: 1.0.0Muthalpha.0fuge 1.0.0Muthalpha.1Mae 1.0.0murrc.0ml1.0.0afrc.1, etc. `CHANGELOG` automatically changes the version number according to the type of information submitted, as follows: * feat: minor version (minor) + 1 * fix: revision number (patch) + 1 * BREAK CHANGE: motherboard number (marjor) + 1 > `CHANGELOG` generated by `CHANGELOG` only contains `fix`, `fix` and `BREACK- CHANGE` submission records # use ```bashnpm I-- save-dev standard-version

Add npm script

{scripts: {"release": "standard-version", "release:alpha": "standard-version-- prerelease alpha", "release:rc": "standard-version-- prerelease rc"}}

Execute:

# npm run scriptnpm run release# or global binstandard-version

Or you want to specify the release number:

# specify type patch/minor/marjornpm run release- release-as patch# specify version number npm run release- release-as 1.1.0 life cycle

Prerelease: before all scripts are executed

Prebump/postbump: before and after changing the version number

Prechangelog/postchangelog: after generating changelog and changelog

Pretag/postag: after generating tag tags and

Standard-version itself is only local, and there is no push to operate. After generating the tag in the last step, we can perform the push operation and add it to the paceage.json.

"standard-version": {"scripts": {"posttag": "git push-follow-tags origin master & & npm publish"}}

There are more configuration features to consult the official documentation.

Other similar tools

In addition to standard-version, there are other similar tools, if you are interested, you can learn about them.

Semantic-release

Lerna

Modify Git Commit

In order to make CHANGELOG.MD more intuitive to see the changes of each version, we try to ensure that each submission is meaningful, but in the actual development process, it is inevitable that some wrong commit message will be submitted. Here are a few git commands to modify commit.

1 modify the last submission of git commit-amend

This command creates a submission and overwrites the last submission, which is appropriate if it is a mistake or is not satisfied with the last submission information.

2 merge multiple submission git reset-- soft [commitID]

If you want to merge the most recent submission information, you need to use the above command to specify the ccommitId to be revoked. This command retains the current changes and revokes all commit records after the specified submission. If you do not specify ID, you can use HEAD~ {num} to select the most recent {num} submission.

Git reset-- soft HEAD~2 # merges the last two submissions git commit-m'feat: add new feat'

The difference with the-- soft parameter is that adding changes to the staging area is equivalent to executing git add.

Git rebase-I

Git rebase will be more powerful. If I want to modify the last 3 submission records, execute

Git rebase-I HEAD~3

The following editor interface (vim editor) appears:

The above shows my last three submission messages, and the following is the command description. The way to modify it is to change the pick before the commit message to the command you need, and then exit: wq save

The following are commonly used command descriptions:

PJ pick = use submission rMagneReword = use commit, but modify submission description eMagie edit = use commit, after exiting, use git commit-- amend modify smaine squash = use commit, merge the previous submission fMagne fixup = the same as squash, but discard the commit description log dJournal drop = delete commit, discard submission record "methods for standardizing GIT code submission information and automated version management", that's it. Thank you for your 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.