diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c61b00d6af..6b5e9aacf8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -17,6 +17,7 @@ Here are some guidelines to get started quickly and easily: - [Branch Naming Conventions](#Branch-Naming-Conventions) - [Pull Request Guidelines](#Pull-Request-Guidelines) - [PR Title Format](#PR-Title-Format) + - [Type and Scope Reference](#Type-and-Scope-Reference) - [PR Description](#PR-Description) - [Special Situations And How To Deal With Them](#Special-Situations-And-How-To-Deal-With-Them) - [Conduct](#Conduct) @@ -167,6 +168,66 @@ Template: The message header is a single line that contains succinct description of the change containing a `commit type`, an optional `scope` and a subject. `commit type` describes the kind of change that this commit is providing: +* feat (new feature) +* fix (bug fix) +* docs (changes to documentation) +* style (formatting, missing semi colons, etc. no code change) +* refactor (refactoring production code) +* test (adding or refactoring tests. no production code change) +* chore (updating grunt tasks etc. no production code change) +* ci (CI/CD configuration) +* perf (performance improvement) +* build (build system changes) +* revert (reverting a previous commit) + +The `scope` can be anything specifying place of the commit change. For example: `framework`, `api`, `tvm`, `db`, `net`. For a full list of scopes, see [Type and Scope Reference](#type-and-scope-reference). You can use `*` if there isn't a more fitting scope. + +The subject contains a succinct description of the change: +1. Limit the subject line, which briefly describes the purpose of the commit, to 50 characters. +2. Start with a verb and use first-person present-tense (e.g., use "change" instead of "changed" or "changes"). +3. Do not capitalize the first letter. +4. Do not end the subject line with a period. +5. Avoid meaningless commits. It is recommended to use the git rebase command. + +Message body uses the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior. + +Here is an example: +``` +feat(block): optimize the block-producing logic + +1. increase the priority that block producing thread acquires synchronization lock +2. add the interruption exception handling in block-producing thread + +Closes #1234 +``` +If the purpose of this submission is to modify one issue, you need to refer to the issue in the footer, starting with the keyword Closes, such as `Closes #1234`,if multiple bugs have been modified, separate them with commas,such as `Closes #123, #245, #992`. + + + +### Branch Naming Conventions +1. Always name the `master` branch and `develop` branch as "master" and "develop". +2. Name the `release_*` branch using version numbers, which are assigned by the project lead (e.g., Odyssey-v3.1.3, 3.1.3, etc.). +3. Use `hotfix/` as the prefix of the `hotfix` branch, briefly describe the bug in the name, and connect words with underline (e.g., hotfix/typo, hotfix/null_point_exception, etc.). +4. Use `feature/` as the prefix of the `feature` branch, briefly describe the feature in the name, and connect words with underline (e.g., feature/new_resource_model, etc.). +### Pull Request Guidelines + +#### PR Title Format + +PR titles must follow the conventional commit format and will be checked by CI: + +``` +type(scope): description +``` + +| Rule | Requirement | +|------|-------------| +| Format | `type: description` or `type(scope): description` | +| Length | 10 ~ 72 characters | +| Type must be one of | `feat` `fix` `refactor` `docs` `style` `test` `chore` `ci` `perf` `build` `revert` | + +#### Type and Scope Reference + +**Type Reference** | Type | Purpose | Example | |------|---------|---------| @@ -182,9 +243,7 @@ The message header is a single line that contains succinct description of the ch | `build` | Build system changes | `build: add aarch64 support for RocksDB` | | `revert` | Reverting a previous commit | `revert: restore ApiUtilTest.java` | -The `scope` is optional and specifies the place or module of the commit change. - -#### Module Scopes +**Module Scopes** | Scope | Description | |-------|-------------| @@ -197,7 +256,7 @@ The `scope` is optional and specifies the place or module of the commit change. | `plugins` | Node tools (Toolkit, ArchiveManifest, database plugins) | | `protocol` | Protocol definitions, protobuf messages, gRPC contracts | -#### Functional Domain Scopes +**Functional Domain Scopes** | Scope | Description | Example | |-------|-------------|---------| @@ -219,7 +278,7 @@ The `scope` is optional and specifies the place or module of the commit change. | `docker` | Docker containerization and deployment | `feat(docker): add ARM64 support` | | `version` | Version and release management | `chore(version): bump to v4.7.8` | -#### Feature Scopes +**Feature Scopes** | Scope | Description | |-------|-------------| @@ -230,51 +289,6 @@ The `scope` is optional and specifies the place or module of the commit change. | `lite` | Lite fullnode functionality | | `toolkit` | Node maintenance tools (Toolkit.jar) | -You can use `*` if there isn't a more fitting scope. - -The subject contains a succinct description of the change: -1. Limit the subject line, which briefly describes the purpose of the commit, to 50 characters. -2. Start with a verb and use first-person present-tense (e.g., use "change" instead of "changed" or "changes"). -3. Do not capitalize the first letter. -4. Do not end the subject line with a period. -5. Avoid meaningless commits. It is recommended to use the git rebase command. - -Message body uses the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior. - -Here is an example: -``` -feat(block): optimize the block-producing logic - -1. increase the priority that block producing thread acquires synchronization lock -2. add the interruption exception handling in block-producing thread - -Closes #1234 -``` -If the purpose of this submission is to modify one issue, you need to refer to the issue in the footer, starting with the keyword Closes, such as `Closes #1234`,if multiple bugs have been modified, separate them with commas,such as `Closes #123, #245, #992`. - - - -### Branch Naming Conventions -1. Always name the `master` branch and `develop` branch as "master" and "develop". -2. Name the `release_*` branch using version numbers, which are assigned by the project lead (e.g., Odyssey-v3.1.3, 3.1.3, etc.). -3. Use `hotfix/` as the prefix of the `hotfix` branch, briefly describe the bug in the name, and connect words with underline (e.g., hotfix/typo, hotfix/null_point_exception, etc.). -4. Use `feature/` as the prefix of the `feature` branch, briefly describe the feature in the name, and connect words with underline (e.g., feature/new_resource_model, etc.). -### Pull Request Guidelines - -#### PR Title Format - -PR titles must follow the conventional commit format and will be checked by CI: - -``` -type(scope): description -``` - -| Rule | Requirement | -|------|-------------| -| Format | `type: description` or `type(scope): description` | -| Length | 10 ~ 72 characters | -| Type must be one of | `feat` `fix` `refactor` `docs` `style` `test` `chore` `ci` `perf` `build` `revert` | - #### PR Description - PR description must not be empty, minimum **20 characters**.