Source: http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html
Every time Git commits the code, it writes a commit message (the commit), otherwise it is not allowed to commit.
-m "hello world"
The parameters of the above code are -m used to specify the commit mesage.
If one line is not enough, you can just execute git commit it and you will jump out of the text editor and let you write multiple lines.
$ git commit
Basically, you can write anything (here, here and here).
However, in general, a commit message should be clearly understood to illustrate the purpose of this submission.
At present, the community has a variety of Commit message code. This article introduces the angular specification (see), which is the most widely used in the current wording, more reasonable and systematic, and has a matching tool.
I. The role of a COMMIT messageThe formatted commit message has several benefits.
(1) Provide more historical information, convenient and quick to browse.
For example, the following command shows the last post-release change, with each commit occupying one row. You know the purpose of a commit only when you look at the beginning of the line.
<last tag> HEAD --pretty=format:%s
(2) Certain commits (such as document changes) can be filtered to facilitate quick search of information.
For example, the following command only shows the new features added to this release.
<last release> HEAD --grep feature
(3) Change log can be generated directly from commit.
Change Log is a document that describes the differences from the previous version when a new version is released, as described later in this article.
Ii. format of the COMMIT messageEach commit, the commit message consists of three parts: Header,body and Footer.
<type>(<scope>): <subject>// 空一行<body>// 空一行<footer>
Where the Header is required, Body and Footer can be omitted.
Regardless of the part, any line must not exceed 72 characters (or 100 characters). This is to avoid the appearance of an automatic line break effect.
2.1 HeaderThe header section has only one row, including three fields: type (required), scope (optional), and subject (required).
(1) Type
typeA category that describes commit, allowing only the following 7 identities to be used.
- Feat: New Feature (feature)
- FIX: Fix bugs
- Docs: Documentation (documentation)
- Style: Format (does not affect changes in code run)
- Refactor: Refactoring (that is, not a new feature, or a code change that modifies a bug)
- Test: Add Tests
- Chore: Changes in the build process or the aid tool
If type feat and fix , the commit will definitely appear in the change log. Other circumstances (,,,, docs chore style refactor test ) You decide, do not put the change log, the proposal is not.
(2) Scope
scopeUsed to describe the scope of the commit impact, such as the data layer, control layer, view layer, etc., depending on the project and different.
(3) Subject
subjectis a short description of the purpose of the commit, no more than 50 characters.
2.2 Body
- Start with a verb, use the first person present tense, for example, instead of
changechangedorchanges- First Letter Lowercase
- End without period (
.)
The Body part is a detailed description of this commit and can be divided into multiple lines. Here is an example.
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. Further paragraphs come after blank lines.- Bullet points are okay, too- Use a hanging indent
There are two points of attention.
(1) Use the first person present time, such as use change instead of changed or changes .
(2) The motive for the change in the code and the comparison with previous behavior should be explained.
2.3 FooterThe Footer section is used only in two cases.
(1) Incompatible changes
If the current code is incompatible with the previous version, the Footer section begins with a description of the BREAKING CHANGE change, the reason for the change, and the migration method.
Breaking change: Before: Scope{myattr: ' attribute ' } after< Span class= "token punctuation" >: Scope{myattr< Span class= "token punctuation" >: ' @ ' for directives so there should is n o Code using It
(2) Close Issue
If the current commit is for a issue, you can close the issue in the Footer section.
#234
You can also turn off multiple issue at once.
2.4 Revert#123, #245, #992
There is also a special case where if the current commit is used to undo a previous commit, it must be preceded by the revert: Header of the revoked commit.
revert: feat(pencil): add ‘graphiteWidth‘ optionThis reverts commit 667ecc1654a317a13331b17617d973392f415f02.
The body part is in a fixed format and must be written with the This reverts commit <hash>. hash SHA identifier of the revoked commit.
If the current commit and the revoked commit are in the same publication (release), then they will not appear in the change log. If the two are in a different release, then the current commit will appear under the Reverts small title of change log.
Commitizen is a tool for writing a qualified Commit message.
The installation commands are as follows.
-g commitizen
Then, in the project directory, run the following command to enable it to support Angular's Commit message format.
$ commitizen init cz-conventional-changelog --save --save-exact
In the future, all git commit orders are used instead git cz . At this point, an option appears to generate a format-compliant Commit message.
The validate-commit-msg is used to check whether the commit message of the Node project conforms to the format.
Its installation is manual. First, copy the following JS file and put it in your code base. The file name can be taken as validate-commit-msg.js .
Next, add the script to the Git hook. Here is the package.json use of ghooks in the inside, to add this script commit-msg when running.
"config": { "ghooks": { "commit-msg": "./validate-commit-msg.js" } }
Then, each time git commit , the script automatically checks if the COMMIT message is qualified. If not qualified, will be an error.
V. Generate change Log-A $ git commit -m "edit markdown" INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" ! was: edit markdown
If all of your commits conform to the Angular format, the change log can be automatically generated with a script (example 1, example 2, example 3) when a new version is released.
The resulting document consists of the following three sections.
- New Features
- BUG fixes
- Breaking changes.
Each section lists the relevant commits and links to those commits. Of course, the resulting document allows for manual modification, so you can add additional content before publishing.
Conventional-changelog is the tool that generates the change log, run the following command.
-g conventional-changelog$ cd my-project$ conventional-changelog -p angular -i CHANGELOG.md -w
The above command will not overwrite the previous change log, only the CHANGELOG.md head plus the changes since the last release.
If you want to generate the change log for all publications, run the following command instead.
$ conventional-changelog -p angular -i CHANGELOG.md -w -r 0
For ease of use, you can write it to package.json a scripts field.
{ "scripts": { "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0" }}
Later, run the following command directly.
$ npm run changelog
Commit message and Change log authoring guide
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
