commit-style

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Commit Style

提交信息风格

Mensagens de commit seguem Conventional Commits. O foco é o porquê da mudança, não o o quê (o diff já mostra o quê).

提交信息遵循Conventional Commits规范。重点是变更的原因，而非内容（diff已经展示了内容）。

Quando usar

使用场景

Usuário pede "commit", "git commit", "commita isso".
Após uma sequência de mudanças prontas para serem registradas.
Quando o histórico precisa de uma entrada nova e descritiva.

用户请求“commit”、“git commit”、“提交这个”时。
完成一系列变更，准备记录到历史记录后。
当需要为历史记录添加新的、描述性的条目时。

Como aplicar

应用方法

Identifique o tipo com base na natureza da mudança:
- ```
feat
```
  — funcionalidade nova
- ```
fix
```
  — correção de bug
- ```
refactor
```
  — mudança de código sem alterar comportamento
- ```
docs
```
  — só documentação
- ```
test
```
  — só testes
- ```
chore
```
  — manutenção, deps, configs sem impacto em runtime
- ```
perf
```
  — melhoria de performance
- ```
style
```
  — formatação (não confundir com mudanças visuais de UI)
Escolha o escopo (opcional, mas recomendado). É a área afetada:
```
feat(auth):
```
,
```
fix(api):
```
,
```
refactor(cli):
```
. Use o nome da pasta/módulo principal modificado.
Escreva o subject (primeira linha):
- Em inglês ou português, mas mantenha consistência no repo.
- Imperativo: "add", "fix", "remove" — não "added", "fixed".
- Sem ponto final.
- Máximo 72 caracteres.
Body (opcional, mas use quando o porquê não é óbvio):
- Linha em branco após o subject.
- Foco no porquê, não no o quê.
- Quebre em 72 caracteres.
Footer (opcional):
- ```
BREAKING CHANGE: <descrição>
```
  para mudanças quebrando compatibilidade.
- ```
Closes #123
```
  ou
```
Refs #123
```
  para issues relacionadas.

根据变更性质确定类型:
- ```
feat
```
  — 新增功能
- ```
fix
```
  — 修复bug
- ```
refactor
```
  — 代码重构，不改变功能
- ```
docs
```
  — 仅修改文档
- ```
test
```
  — 仅修改测试
- ```
chore
```
  — 维护工作、依赖更新、配置变更，不影响运行时
- ```
perf
```
  — 性能优化
- ```
style
```
  — 代码格式调整（不要与UI视觉变更混淆）
选择作用域（可选，但推荐）。即受影响的区域：
```
feat(auth):
```
、
```
fix(api):
```
、
```
refactor(cli):
```
。使用被修改的主文件夹/模块名称。
编写主题（第一行）:
- 可以用英文或葡萄牙语，但仓库内要保持一致。
- 使用祈使语气：“add”、“fix”、“remove” — 不要用“added”、“fixed”。
- 末尾不要加句号。
- 最多72个字符。
正文（可选，但当变更原因不明显时使用）:
- 主题后空一行。
- 重点放在原因，而非内容。
- 每行不超过72个字符。
页脚（可选）:
- 对于破坏性变更，使用
```
BREAKING CHANGE: <描述>
```
  。
- 使用
```
Closes #123
```
  或
```
Refs #123
```
  关联相关议题。

Exemplos

示例

Bom:

feat(auth): add token refresh flow

Sessions were expiring mid-task and forcing users to restart.
The refresh runs silently 30s before expiry.

Closes #142

Bom (curto):

fix(cli): handle empty skills/ directory without crashing

Ruim:

update files

Ruim (foco no o quê, não no porquê):

fix: change line 42 of auth.ts to use Date.now()

良好示例:

feat(auth): add token refresh flow

Sessions were expiring mid-task and forcing users to restart.
The refresh runs silently 30s before expiry.

Closes #142

简短的良好示例:

fix(cli): handle empty skills/ directory without crashing

不良示例:

update files

不良示例（重点在内容而非原因）:

fix: change line 42 of auth.ts to use Date.now()

Anti-padrões

反模式

Mensagens genéricas: "update", "fix stuff", "wip".
Misturar múltiplos tipos no mesmo commit. Se você adicionou feature E corrigiu bug, são 2 commits.
Subject em passado: "added", "fixed". Use imperativo.
Body explicando o diff linha-a-linha — o diff já está lá.
Usar
```
feat
```
para coisas que não são features (renomear arquivo =
```
refactor
```
, não
```
feat
```
).

通用化消息：“update”、“fix stuff”、“wip”。
同一提交混合多种类型。如果既新增功能又修复bug，应拆分为2个提交。
主题使用过去式：“added”、“fixed”。请使用祈使语气。
正文逐行解释diff内容——diff本身已经存在。
将非功能类变更标记为
```
feat
```
（重命名文件属于
```
refactor
```
，而非
```
feat
```
）。