API 浏览器
如何贡献
贡献指南
正在运行的项目
开始新项目
项目维护者角色
提交约定
提交约定

目标(Goals)

¥Goals

  • 允许忽略 git bisect 的提交（例如格式化等非重要提交）

    ¥Allow ignoring commits by git bisect (not important commits like formatting)

  • 在浏览历史记录时提供更清晰的信息

    ¥Provide better information when browsing the history

警告

此规则适用于所有 Quasar 代码库 插件。

¥This rule applies to ALL Quasar repositories.

精心维护的日志既美观又实用。git blame、revert、rebase、 log、shortlog 和其他子命令开始生效。审查他人的提交和拉取请求变得值得一做，而且突然间可以独立完成。了解几个月或几年前发生的事情的原因不仅成为可能，而且更加高效。

¥Well-cared log is a beautiful and useful thing. git blame, revert, rebase, log, shortlog and other subcommands come to life. Reviewing others’ commits and pull requests becomes something worth doing, and suddenly can be done independently. Understanding why something happened months or years ago becomes not only possible but efficient.

优秀的 Git 提交消息规则(The Rules of a Great Git Commit Message)

¥The Rules of a Great Git Commit Message

  1. 用空行分隔主题和正文

    ¥Separate subject from body with a blank line

  2. 将主题行限制为 70 个字符

    ¥Limit the subject line to 70 characters

  3. 主题行请大写

    ¥Capitalize the subject line

  4. 不要以句号结尾主题行。

    ¥Do not end the subject line with a period

  5. 在主题行中使用祈使语气

    ¥Use the imperative mood in the subject line

  6. 在 80 个字符处换行

    ¥Wrap the body at 80 characters

  7. 使用正文解释“什么”和“为什么”以及“如何”

    ¥Use the body to explain what and why vs. how

提交消息格式(Format of a Commit Message)

¥Format of a Commit Message

type(<scope>): <Subject> #<github-ref-id>

<body>

<footer>

提交消息示例(Example of a Commit Message)

¥Example of a Commit Message

fix(ui): Ensure Range headers adhere more closely to RFC 2616 #2310

To add new dependency use `range-parser`to compute the range.
It is more well-tested in the wild.

BREAKING CHANGE:
port-runner command line option has changed to runner-port.
To migrate your project, change all the commands,
where you use --port-runner to --runner-port.

消息主题（首行）(Message Subject (First Line))

¥Message Subject (First Line)

第一行不能超过 70 个字符，第二行始终为空。类型和作用域应始终小写，如下所示。

¥The first line cannot be longer than 70 characters, the second line is always blank. The type and scope should always be lowercase as shown below.

允许的 <type> 值：

¥Allowed <type> values:

  • feat - 这是用户的新功能，而不是构建脚本的新功能

    ¥feat - new feature for the user, not a new feature for build script

  • fix - 修复用户的错误，而不是修复构建脚本。

    ¥fix - bug fix for the user, not a fix to a build script

  • docs - 仅文档变更

    ¥docs - documentation only changes

  • style - 不影响代码含义的更改（空格、格式、缺少分号等）

    ¥style - changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

  • refactor - 重构生产代码，代码变更既不修复错误也不添加功能

    ¥refactor - refactoring production code, a code change that neither fixes a bug nor adds a feature

  • chore - 其他不修改 src 或测试文件的更改（不更改生产代码）和依赖更新

    ¥chore - other changes that don’t modify src or test files (no production code change) and dependency updates

  • perf - 改进性能的更改

    ¥perf - change that improves performance

  • revert - 还原上一次提交

    ¥revert - reverts a previous commit

  • test - 添加缺失的测试，重构测试；无需更改生产代码

    ¥test - adding missing tests, refactoring tests; no production code change

  • build - 影响构建系统或外部依赖的更改（例如 ui/build/*）

    ¥build - changes that affect the build system or external dependencies (e.g. ui/build/*)

  • ci - 持续集成配置文件和脚本的更改（例如 GitHub Actions）

    ¥ci - changes to our Continuous Integrations configuration files and scripts (e.g. GitHub Actions)

<scope> 值示例：

¥Example <scope> values:

  • 目录/包相关：ui、cli、app-webpack、app-vite 等

    ¥Directory/package related: ui, cli, app-webpack, app-vite, etc.

  • 功能相关：api、TouchSwipe、QTime 等。

    ¥Feature related: api, TouchSwipe, QTime, etc.

提示

<scope> 可以包含多个值，并用 & 符号分隔（&）。示例：feat(app-vite&app-webpack): Add Capacitor mode。

¥The <scope> can contain more values separated by ampersand(&). Example: feat(app-vite&app-webpack): Add Capacitor mode.

<scope> 可以为空（例如，如果更改是全局的），在这种情况下省略括号。示例：style: Use semicolons

¥The <scope> can be empty (e.g. if the change is global), in which case the parentheses are omitted. Example: style: Use semicolons

消息正文(Message Body)

¥Message Body

  • 使用祈使句，现在时：“change” 不是 “changed” 也不是 “changes”

    ¥uses the imperative, present tense: “change” not “changed” nor “changes”

  • 包含更改的动机并与之前的行为进行对比

    ¥includes motivation for the change and contrasts with previous behavior

消息页脚(Message Footer)

¥Message Footer

重大变更(Breaking Changes)

¥Breaking Changes

所有重大变更都必须在页脚中以“重大变更”块的形式提及，并以“BREAKING CHANGE”开头：使用空格或两个换行符。提交消息的其余部分是对变更、理由和迁移说明的描述。

¥All breaking changes have to be mentioned as a breaking change block in the footer, which should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then the description of the change, justification and migration notes.

BREAKING CHANGE: isolate scope bindings definition has changed and
    the inject option for the directive controller injection was removed.

    To migrate the code follow the example below:

    Before:

    scope: {
      myAttr: 'attribute',
      myBind: 'bind',
      myExpression: 'expression',
      myEval: 'evaluate',
      myAccessor: 'accessor'
    }

    After:

    scope: {
      myAttr: '@',
      myBind: '@',
      myExpression: '&',
      // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
      myAccessor: '=' // in directive's template change myAccessor() to myAccessor
    }

引用问题(Referencing Issues)

¥Referencing Issues

已关闭的问题应在页脚中单独一行列出，并以 “关闭” 关键字为前缀，如下所示：

¥Closed issues should be listed on a separate line in the footer prefixed with “Closes” keyword like this:

Closes #234

或者在出现多个问题的情况下：

¥or in the case of multiple issues:

Closes #123, #245, #992

Ready for more?
如何贡献
项目维护者角色
选项和助手
$q 对象
1. Introduction
2. 目标(Goals)
3. 优秀的 Git 提交消息规则(The Rules of a Great Git Commit Message)
4. 提交消息格式(Format of a Commit Message)
4.1. 提交消息示例(Example of a Commit Message)
5. 消息主题（首行）(Message Subject (First Line))
6. 消息正文(Message Body)
7. 消息页脚(Message Footer)
7.1. 重大变更(Breaking Changes)
7.2. 引用问题(Referencing Issues)
Quasar v2.18 中文网 - 粤ICP备13048890号