commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Commit

代码提交

Pre-commit workflow and commit guidelines.

提交前工作流与代码提交规范。

Pre-commit Checklist

提交前检查清单

Before making ANY commit:

Run the
```
lint
```
skill's workflow — all checks must pass with zero issues (abort if any issues remain). Follow the
```
lint
```
skill — full check, no
```
--tools
```
filtering.
All tests must pass (
```
uv run lintro tst
```
)
Where applicable, Docker builds pass

在进行任何提交之前：

运行
```
lint
```
技能的工作流 —— 所有检查必须零问题通过（若有任何问题则终止提交）。遵循
```
lint
```
技能要求 —— 全面检查，不使用
```
--tools
```
过滤。
所有测试必须通过（
```
uv run lintro tst
```
）
若适用，Docker构建需通过

Commit Requirements

提交要求

Every commit MUST be signed/verified

Use semantic commit prefixes:

fix:

feat:

chore:

docs:

refactor:

test:

build:

ci:

perf:

style:

Commit messages MUST be in imperative mood ("Add feature" not "Added feature")

每一次提交必须经过签名/验证

使用语义化提交前缀：

fix:

feat:

chore:

docs:

refactor:

test:

build:

ci:

perf:

style:

提交信息必须使用祈使语气（例如"Add feature"而非"Added feature"）

Commit Granularity

提交粒度

Make incremental, logical commits rather than one large commit:

Group related changes (e.g., all logging for one subsystem)
Separate concerns (e.g., bug fixes vs features vs docs)
Each commit should be independently reviewable and revertable
Use judgment: 1 commit per file is too granular, 1 commit for everything is too coarse

Good groupings:

feat(logging): add subprocess execution logging

(one component)

feat(logging): add config parsing logging

(related files)

```
docs: add debugging guide
```
(documentation separate from code)

Bad groupings:

One commit with 11 files touching 4 different concerns
11 separate commits for a cohesive feature

做增量的、逻辑化的提交，而非单次大提交：

归类相关更改（例如，某个子系统的所有日志相关修改）
分离不同关注点（例如，bug修复、功能新增、文档更新分开）
每个提交应可独立评审和回滚
合理判断：每个文件单独提交过于细碎，所有内容一次提交过于粗糙

合理的归类示例：

feat(logging): add subprocess execution logging

（单个组件）

feat(logging): add config parsing logging

（相关文件）

```
docs: add debugging guide
```
（文档与代码分开）

不合理的归类示例：

单次提交包含11个文件，涉及4个不同关注点
一个完整功能拆分为11次独立提交

Branch Context Awareness

分支上下文注意事项

When working on a new extension or feature branch where all files are new:

Every file should show as "A" (added), never "M" (modified)
If you see "M" on files that should be new, the commit history needs fixing
This indicates commits were made in the wrong order or need restructuring

When modifying an existing codebase:

"M" (modified) is expected and correct
Focus on logical grouping of related changes

在新扩展或功能分支上工作时，所有文件都应为新增状态：

所有文件应显示为"A"（已添加），而非"M"（已修改）
如果本该新增的文件显示为"M"，则提交历史需要修复
这表明提交顺序错误或需要重构

在修改现有代码库时：

"M"（已修改）是正常且正确的
重点关注相关更改的逻辑归类

Restructuring Commits

重构提交历史

If commits are poorly structured (too large, wrong groupings, or showing modified when should be added):

Find the commit before the problematic ones:
```
git log --oneline
```
Soft reset to that point:
```
git reset --soft <good-commit>
```
Unstage all changes:
```
git reset HEAD
```
Re-add and commit in logical groups with proper messages
Verify with
```
git status
```
that file statuses (A/M) are correct

如果提交结构不合理（过大、归类错误，或本该新增的文件显示为已修改）：

找到有问题的提交之前的那个提交：
```
git log --oneline
```
软重置到该提交：
```
git reset --soft <good-commit>
```
取消所有暂存的更改：
```
git reset HEAD
```
重新添加并按逻辑分组提交，使用规范的提交信息
通过
```
git status
```
验证文件状态（A/M）是否正确

Usage

使用流程

When asked to commit:

Run the
```
lint
```
skill's workflow — abort if any issues remain (follow the
```
lint
```
skill — full check, no
```
--tools
```
filtering)
- Raycast extensions: run
```
uv run lintro fmt/chk
```
  first, then
```
npm run lint
```
  per the
```
raycast
```
  skill (Raycast rules take precedence)
- Other projects without lintro: use the appropriate lint command from the
```
lint
```
  skill
Run tests - abort if any failures:
- Projects with lintro:
```
uv run lintro tst
```
- Raycast extensions: run Vitest if the extension has tests configured (
```
bun test
```
  or the extension's test script); otherwise manual smoke test via
```
bun run dev
```
  (see the
```
raycast
```
  skill)
- Other projects: use appropriate test command
- When authoring or modifying a Raycast extension, use the
```
raycast
```
  skill for toolchain-specific guidance
Check Docker if applicable
Review changes with
```
git status
```
to plan logical groupings
Stage and commit in logical groups with signed, semantic, imperative messages:
bash
```
git add <related-files>
git commit -S -m "feat: add user authentication"
```
Repeat steps 4-5 for each logical group of changes

当需要提交更改时：

运行
```
lint
```
技能的工作流 —— 若有任何问题则终止提交（遵循
```
lint
```
技能要求 —— 全面检查，不使用
```
--tools
```
过滤）
- Raycast extensions: 先运行
```
uv run lintro fmt/chk
```
  ，再根据
```
raycast
```
  技能运行
```
npm run lint
```
  （Raycast规则优先）
- 其他无lintro的项目：使用
```
lint
```
  技能中的对应代码检查命令
运行测试 - 若有失败则终止提交：
- 有lintro的项目：
```
uv run lintro tst
```
- Raycast extensions: 如果扩展配置了测试，则运行Vitest（
```
bun test
```
  或扩展的测试脚本）；否则通过
```
bun run dev
```
  进行手动冒烟测试（参考
```
raycast
```
  技能）
- 其他项目：使用对应测试命令
- 编写或修改Raycast扩展时，参考
```
raycast
```
  技能获取工具链相关指导
若适用，检查Docker构建
通过
```
git status
```
查看更改，规划逻辑分组
按逻辑分组暂存并提交，使用签名的、语义化的、祈使语气的提交信息：
bash
```
git add <related-files>
git commit -S -m "feat: add user authentication"
```
重复步骤4-5，处理每个逻辑分组的更改

Examples

示例

Good commit messages:

fix: resolve null pointer in user service

```
feat: add dark mode toggle
```
```
chore: update dependencies
```
```
docs: improve API documentation
```
```
refactor: simplify authentication flow
```

Bad commit messages:

```
fixed bug
```
(not semantic, past tense)
```
WIP
```
(not descriptive)
```
updates
```
(not semantic, not specific)

规范的提交信息：

fix: resolve null pointer in user service

```
feat: add dark mode toggle
```
```
chore: update dependencies
```
```
docs: improve API documentation
```
```
refactor: simplify authentication flow
```

不规范的提交信息：

```
fixed bug
```
（无语义化前缀，过去式）
```
WIP
```
（描述不清晰）
```
updates
```
（无语义化前缀，不具体）