preface
The previous part mainly introduced Readme in Vue3. After reading the Readme documentation and understanding the features and features of Vue3, you can begin to prepare targeted in-depth source code. A good way to start looking at the source code is to take a look at the Git Log to get a glimpse of the commit process throughout the development cycle. In the process of looking at the Log of Vue3, we found that its specification and verification methods are of great benefit to the usual business development, so this article will share the content related to the Log specification.
content
- Open git visualization tool (recommended soureTree for MAC, recommended Tortoisegit for Window). The screenshot below is part of vue3 annotation, which can be clearly seen with standard format specification. Can by type (feat | fix | computer | dx | style | refactor | perf | test | workflow | build | ci | chore | types | the wip) and the content clearly distinguish between the content of the submitted function, etc.
- The vuE3 specification, in addition to conventions,./script/verifyCommit.jsThe gitHook commit-msg hook performs the validation. Commit to MSG automatic validation specification.
- Git Log specifications are used for three purposes
- Changelog.md is automatically generated
- Identify unimportant commits
- Provides better information when browsing the submission history
- How do I customize my own set of specifications
Here is a set of annotation specifications for reference Refer to the reference:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Copy the code
-
Subject is a brief description of the change.
-
Body is a more detailed description.
-
Used to illustrate the scope of the commit impact
-
Type defines the type of the change, which can be increased or decreased according to the service
-Dan: It's a fix for the docs. -Dan: It's a code style change that doesn't affect functionality. -Dan: It's a code change that's neither a new feature nor a fix. Development tools (builds, scaffolding tools, etc.) footers can contain Breaking Changes and watches information.Copy the code
conclusion
Here you can recall the usual business development whether there is the development of the relevant annotations specification, is the stereotype or mandatory. If not, and the purpose and content of the submission cannot be distinguished by Log during troubleshooting, then it is time to develop an annotation specification suitable for your project in the latest iteration. In this way, it is recommended to agree first, and determine whether to add strong verification according to the implementation effect of the agreement. If it is a front-end project especially god’s verification code can be taken in the past simple modification directly used. If it is other types of projects, you can do a little research, should not cost high.
Keyword Search
Git Log specification Githook Changlog
Divergence problem
- If the project is Java, go or other languages, what is the general verification method for git log format? Is there a general verification method
The above problems, usually in the work of understanding or have the best practice of the students can also share with us to discuss and improve