mirrors/dae
1
0
Fork 0
mirror of https://github.com/daeuniverse/dae.git synced 2025-01-13 00:04:47 +07:00
Code Issues Packages Projects Releases Wiki Activity
9f04adfe16
dae/docs/en/development/commit-msg-guide.md
Kevin Yu e39ec7fc05
refactor(/docs): rework documentation structure layout (#179) 
* refactor(/docs): rework documentation structure layout

* refactor(/docs): update file reference paths

* feat(/docs): add English version of other-proxy-protocol.md

* refacotr: move docs/templates/ docs/sync/ to hack/

* fix(example.dae|readme): update ref link to adopt new file structure

* refactor: rename other-proxy-protocol.md -> proxy-protocols.md

* docs(readme): add ref to proxy-protocols.md

* feat(/docs): add English version of how-it-works.md

* refactor: rename how-it-works; add nav links

* fix: fix linting errors

* fix: fix linting errors

---------

Co-authored-by: earrmouth <43926351+earrmouth@users.noreply.github.com>
2023-07-09 17:31:47 +08:00

2.4 KiB
Raw Blame History

Semantic Commit Messages

The reasons for these conventions

  • automatic generating of the changelog
  • simple navigation through Git history (e.g. ignoring the style changes)

See how a minor change to your commit message style can make you a better developer.

Format

`<type>(<scope>): <subject>`

`<scope>` is optional

Example

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

Example <type> values:

  • feat: (new feature for the user, not a new feature for build script)
  • fix: (bug fix for the user, not a fix to a build script)
  • docs: (changes to the documentation)
  • style: (formatting, missing semi colons, etc; no production code change)
  • refactor: (refactoring production code, eg. renaming a variable)
  • test: (adding missing tests, refactoring tests; no production code change)
  • chore: (updating grunt tasks etc; no production code change, e.g. dependencies upgrade)
  • perf: (perfomance improvement change, e.g. better concurrency performance)
  • ci: (updating CI configuration files and scripts e.g. .gitHub/workflows/*.yml )

Example <Scope> values:

  • init
  • runner
  • watcher
  • config
  • web-server
  • proxy

The <scope> can be empty (e.g. if the change is a global or difficult to assign to a single component), in which case the parentheses are omitted. In smaller projects such as Karma plugins, the <scope> is empty.

Message Subject (First Line)

The first line cannot be longer than 72 characters and should be followed by a blank line. The type and scope should always be lowercase as shown below

Message Body

use as in the <subject>, use the imperative, present tense: "change" not "changed" nor "changes". Message body should include motivation for the change and contrasts with previous behavior.

Message footer

Referencing issues

Closed issues should be listed on a separate line in the footer prefixed with "Closes" keyword as the following:

Closes #234

or in the case of multiple issues:

Closes #123, #245, #992

References