write-conventional-commit
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseWrite Conventional Commit
编写Conventional Commit提交信息
Inspect Git changes and return exactly one final commit message.
检查Git变更并仅返回一条最终提交信息。
Workflow
工作流程
- Run .
git status --short - If there are no staged or unstaged changes, reply exactly:
No staged or unstaged changes found. - Run .
git diff --staged --no-ext-diff --stat - Run .
git diff --staged --no-ext-diff - If the staged diff is empty but the working tree is dirty, use and
git diff --no-ext-diff --statas a fallback.git diff --no-ext-diff - Infer the dominant intent from the diff and write one message only.
- Return exactly one final commit message and nothing else.
- 运行 。
git status --short - 如果没有暂存或未暂存的变更,精确回复:
No staged or unstaged changes found. - 运行 。
git diff --staged --no-ext-diff --stat - 运行 。
git diff --staged --no-ext-diff - 如果暂存区的diff为空但工作区有未提交变更,则使用 和
git diff --no-ext-diff --stat作为备选。git diff --no-ext-diff - 从diff中推断核心意图,仅编写一条提交信息。
- 仅返回最终的提交信息,不包含其他内容。
Commit Types
提交类型
Use exactly one type from this list:
- feat: a new feature
- fix: a bug fix
- docs: documentation only changes
- style: changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: a code change that neither fixes a bug nor adds a feature
- perf: a code change that improves performance
- test: adding missing tests or correcting existing tests
- build: changes that affect the build system or external dependencies
- ci: changes to our CI configuration files and scripts
- chore: other changes that don't modify src or test files
必须从以下列表中选择一种类型:
- feat: 新增功能
- fix: 修复bug
- docs: 仅修改文档
- style: 不影响代码含义的变更(空白字符、格式调整、缺失分号等)
- refactor: 既不修复bug也不新增功能的代码变更
- perf: 提升性能的代码变更
- test: 添加缺失的测试或修正现有测试
- build: 影响构建系统或外部依赖的变更
- ci: 修改CI配置文件或脚本
- chore: 其他不修改源码或测试文件的变更
Conventional Commit rules
Conventional Commit规则
- Choose the dominant intent. DO NOT combine types.
- DO NOT end the subject with a period.
- If the change is breaking, mark it with after the type or scope and include a
!footer when additional migration detail is needed.BREAKING CHANGE: - Keep the subject concise; aim for 50-72 characters.
- Never include markdown fences, bullets, analysis, or commentary.
- Prefer a longer commit body after the short description, providing additional contextual information about the code changes.
- Prefer lower-case after the colon unless a proper noun or acronym requires capitalization.
- Preserve useful trailer/footer information from the context when it is clearly present.
- Use an optional scope only when it is obvious and genuinely helpful.
- Write the subject in imperative mood.
- 选择核心意图,禁止合并多种类型。
- 主题部分结尾不要加句号。
- 如果是破坏性变更,在类型或作用域后添加,当需要额外迁移细节时,需包含
!页脚。BREAKING CHANGE: - 主题部分要简洁,目标长度为50-72个字符。
- 禁止包含markdown围栏、项目符号、分析或注释内容。
- 建议在简短描述后添加较长的提交正文,提供代码变更的额外上下文信息。
- 冒号后优先使用小写,除非专有名词或首字母缩写需要大写。
- 当上下文明确包含有用的尾部/页脚信息时,予以保留。
- 仅当作用域明确且真正有帮助时,才使用可选的作用域。
- 主题部分使用祈使语气。