Git submission specification

  • Refer to the specificationAngular’s commit convention.
    • featAdd new features
    • fixFix problems/bugs
    • styleCode style dependence does not affect the results of the run
    • perfOptimization/performance improvement
    • refactorrefactoring
    • revertUndo modify
    • testRelevant test
    • docsDocumentation/comments
    • choreDependency updates/scaffold configuration modifications, etc
    • workflowWorkflow improvement
    • ciContinuous integration
    • typesType definition file changes
    • wipThe development of

Submit message format

Each submit message consists of a header, a body, and a footer.

<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Copy the code

The header is mandatory and the scope of the header is optional. And must conform to the submission header format.

All submissions are mandatory except for the body submission of type “Document”. When the body appears, it must be at least 20 characters long and must conform to the submission message body format.

Footer is optional. The commit message footer format describes the purpose of the footer and the structure it must have.

Submit headers

<type>(<scope>): │ │ ├ ─ ├ ─ sci-press (⫸) │ ├ ─ sci-press <short summary> │ │ │ ├ ─ sci-press (⫸) │ │ ├ ─ sci-press (⫸) Animations | bazel | benchpress | common | compiler | compiler - cli | core | │ Elements | forms HTTP | | language - service | localize | platform - browser | │ Platform - the browser - dynamic | platform - server | router | service - worker | │ Upgrade | zone. Js | packaging | changelog | docs - infra | migrations | NGCC | ve │ └ ─ ⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|testCopy the code

The

and

fields are required, and the fields (

) are optional.

Type

Must be one of the following:

  • Build: Changes to build system or external dependencies (example range: gulp, BROCCOLI, NPM)
  • Ci: Change our CI profiles and scripts (e.g. CircleCi, SauceLabs)
  • Docs: Only documents are changed
  • Feat: A new feature
  • Fix: error repair
  • Perf: Code changes that improve performance
  • Refactor: Code changes that neither fix bugs nor add functionality
  • Test: Add missing tests or correct existing tests

Scope

The scope should be the name of the affected NPM package (as perceived by someone reading the change log generated by the commit message).

Here is a list of supported ranges:

  • animations
  • bazel
  • benchpress
  • common
  • compiler
  • compiler-cli
  • core
  • elements
  • forms
  • http
  • language-service
  • localize
  • platform-browser
  • platform-browser-dynamic
  • platform-server
  • router
  • service-worker
  • upgrade
  • zone.js

There are currently some exceptions to the “Use package name” rule:

  • packaging: changes used to change the NPM package layout in all our packages, such as common path changes, package.json changes made to all packages, D.ts file/format changes, changes to packages, etc.
  • changelog: Used to update the release notes in Changelog. md
  • dev-infra: for dev-infra-related changes in the directories /scripts and /tools
  • docs-infra: for changes related to docs-app (angular.io) in the REPo/aiO directory
  • migrations: Used to changeng updateThe migration.
  • ngcc: Used to changeAngular compatibility compiler
  • ve: for ViewEngine (older compiler/renderer) specific changes.
  • None/Empty String: for all packages (for example)testChanges to and document changes (for example) that are not specific to a particular package are useful.refactor``test: add missing unit tests``docs: fix typo in tutorial

summary

Use the summary field to provide a concise description of the changes:

  • Use the imperative, present tense: “change” is not “changed” nor “changes”
  • Don’t capitalize the first letter
  • There is no dot at the end (.)

Submit headers

As in the summary, use the imperative, present tense: “fix” is neither “fixed” nor “fixes”.

Explain the motivation for committing changes in the message body. This commit message should explain why you made the change. You can compare the previous behavior to the new behavior to illustrate the impact of the change.

Submit the message footer

The footer can contain information about significant changes and deprecations, and is also a place to reference issues, Jira Tickets, and other PR that this submission closes or is related to. Such as:

BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
Fixes #<issue number>
Copy the code

or

DEPRECATED: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>
<BLANK LINE>
<BLANK LINE>
Closes #<pr number>
Copy the code

The major CHANGE section should begin with the phrase BREAKING CHANGE:, followed by a major CHANGE summary, blank lines, and a detailed description of the major CHANGE including migration instructions.

Similarly, the DEPRECATED section should begin with DEPRECATED:, followed by a short description of the DEPRECATED content, blank lines, and a detailed description of the DEPRECATED content, with a reference to the recommended update path.

Reduction to submit

If a commit reverts a previous commit, it should begin revert:, followed by the revert header.

The body of the submission message should contain:

  • Information about the submitted SHA that is being restored is in the following format:This reverts commit <SHA>.
  • Clearly describe the reason for resuming the commit message.

The sample