ce-commit
everyinc/compound-engineering-plugin
使用清晰传达价值的信息创建 git 提交。当用户要求以与仓库相符且能传达价值的信息提交/保存已暂存或未暂存的更改时,使用此操作。
...展开全部关于 ce-commit
一个工作流,用于从当前工作树生成单个、精心制作的 Git 提交,其提交信息在存在仓库约定时传达价值并遵循仓库约定,否则遵循常规提交格式。当用户要求提交、保存更改或从暂存或未暂存的更改创建提交时,该工作流即被激活。在 Claude Code 上,它直接消耗预填充的 Git 状态、工作树差异、当前分支、最近提交和远程默认分支部分;在其他平台上,它运行单个回退命令以收集相同的上下文。
该工作流分五个步骤运行。第一步收集上下文并处理边缘情况:干净的树意味着没有可提交的内容,而分离的 HEAD 会通过平台的阻塞问题工具提示用户是否创建功能分支。第二步按优先级确定消息约定,优先采用文档化的仓库约定,然后是从最近十个提交中推断出的模式,否则采用形式为 type scope description 的常规提交,类型包括 feat、fix、docs、refactor、test、chore、perf、ci、style 和 build;当 fix 和 feat 均适用时,默认选择 fix。第三步轻度考虑将明显不同的关注点拆分为单独的提交,仅在文件级别进行分组,并将两个或三个逻辑提交视为最佳数量。
第四步进行暂存和提交,如果当前分支是 main、master 或解析后的默认分支,则自动先创建功能分支,而不是在默认分支上提交。消息使用简洁的祈使句主题,侧重于“为什么”而非“是什么”,可选正文用于非琐碎的更改;暂存操作优先命名特定文件,而不是使用 git add all,以避免包含敏感文件;提交使用 heredoc 编写以保留格式。第五步通过运行 git status 并报告生成的提交哈希和主题行来确认成功。
常见问题
它默认使用什么提交消息格式?
它优先采用文档化的仓库约定,然后是从最近十个提交中推断出的模式,否则回退到形式为 type scope: description 的常规提交。
它会在 main 分支上直接提交吗?
不会。如果当前分支是 main、master 或解析后的默认分支,它会自动先创建功能分支,然后再提交。
它何时选择 fix 而非 feat?
当两者似乎都适用时,默认选择 fix,将修复损坏或缺失行为的变化视为 fix,并将 feat 保留给真正的新功能。
它会将更改拆分为多个提交吗?
它会轻度扫描明显不同的关注点,并可能创建仅在文件级别分组的单独提交,其中两个或三个逻辑提交被视为最佳数量。
它如何避免提交敏感文件?
它优先按名称暂存特定文件,而不是使用 git add -A 或 git add .,以避免意外包含 .env 或凭据等文件。
Create well-crafted local commit(s) from the current working tree. No push, no PR — use ce-commit-push-pr for the full ship flow.
Done when: each logical change is committed with an explicit file list and a message that states the outcome, and git status is clean of those changes. Stop when: the tree is clean (nothing to commit).
Context
Gather context with each command as its own shell tool call (program + args only). Do not join with ;, &&, ||, pipes, $(...), or redirects — that syntax fails under Windows PowerShell. A non-zero exit is a normal state to interpret, not a failure to suppress.
| Command | Purpose | Non-zero / empty means |
|---|---|---|
git status | Working-tree state | Not a git repo — stop |
git diff HEAD | Uncommitted changes | Unborn repo / no commits yet |
git branch --show-current | Current branch | Empty = detached HEAD |
git log --oneline -10 | Recent message style | Unborn repo — no history |
git rev-parse --abbrev-ref origin/HEAD | Remote default branch | No origin/HEAD / bare HEAD — try gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name', else main |
Treat this as a snapshot. Re-read branch and staged set immediately before committing if anything may have changed.
Default branch name: strip a leading origin/ from origin/HEAD (so origin/trunk → trunk). Use that bare name for all “on the default branch?” checks — never compare against origin/<name>.
Workflow
Gather — run every Context command above (own shell call each), then continue.
Nothing to commit — if
git statusshows no staged, modified, or untracked files, report that and stop. Do not usegit diff HEADalone as cleanliness (it misses untracked files).Branch first — if detached HEAD, or on the default branch (
main/master/ the bare default name above), create a feature branch from the change content (git checkout -b <name>), then re-readgit branch --show-current. Do not ask — commit-only still must not leave work only on a detached HEAD or the default branch. If the derived name exists, pick a non-conflicting suffix.Convention — match project commit conventions already in context; else match the recent log pattern; else conventional commits (
type(scope): description). When using conventional commits andfix/featboth fit, default tofix:(remedying broken or missing behavior); reservefeat:for new capabilities. User override wins.Logical commits — if changed files clearly split into distinct concerns, make separate commits (file level only, 2–3 max, no
git add -p). If ambiguous, one commit.Message — subject is imperative and names the outcome (what is now possible or fixed), not the file list. Body only when motivation or trade-offs are not obvious from the subject. When a plan Implementation Unit ID is already in hand for this commit (conversation, caller, or the files belong to one unit), append that unit's U-ID in parentheses —
(U3)means unit 3. Do not hunt for a plan. Omit when the commit spans units, the unit is unclear, or no plan is in hand.- Bad:
Update checkout.rb/Add tests and fix stuff - Good:
Fix double-submit on checkout - Good:
Add per-subscription mute (U3)
- Bad:
Stage and commit — stage named files only (never
git add -Aorgit add .). Honorexclude:<paths>when the invocation carries it: those files stay uncommitted no matter what else changed; say in the report that they were left out. Prefer one shell call per commit group:
git add file1 file2 file3 && git commit -m "$(cat <<'EOF'type(scope): subject line hereOptional body when the why is not obvious from the subject.EOF)" -- file1 file2 file3
The trailing path list on git commit is load-bearing: a bare git commit takes the whole index, so anything already staged before this run (a caller's exclude: paths, or work the user staged and did not name) would ride into the commit. Naming the paths commits exactly the group and leaves other index entries alone.
- Confirm —
git status; report hash(es) and subject(s).





首页
