commitkit

commitkit

将当前更改整理为一个或多个整洁的提交，并根据 diff 本身推断 Conventional Commits 提交消息，而不是凭空猜测。提交消息应以祈使语气准确描述实际更改，并使用正确的类型和范围。在编码会话中，默认应创建多个提交，每个功能组或逻辑相关的更改各一个，绝不把所有内容塞进单个大杂烩提交。

何时触发

用户要求提交时（“提交这个”“创建一个提交”“/commitkit”“提交我的更改”）。如果用户只要提交消息（“起草一条提交消息”“消息应该怎么写”），则走仅消息流程，绝不暂存、提交或推送。若调用方希望提交但不推送，则使用 no-push（“只提交，不要推送”）；请参阅提交每个分组。如果提交请求暂缓文档审查（“之后再审查”），或者报告文档已审查，则在执行流程前走审查标记。

这项技能面向用户在 AI 编码会话结束时只说一句“提交”的情形。在这种模式下，你应自主处理：自行暂存本次会话的文件，根据工作内容合理拆分为多个提交，完成提交、推送，并以表格汇报创建的提交，不要在每一步都停下来询问。唯一预先计划的问题是分支问题：在采用分支工作流的仓库中，如果你位于基础分支上。

范围

一次运行提交的是本次会话的更改，而不是工作区中的所有更改。同一分支或工作树往往同时包含其他 Agent 或其他会话所做的多个修复，运行时应保持这些更改原样。分组前先确定范围，并采用第一个匹配的规则：

1. all（/commitkit all、“提交所有内容”、“提交全部更改”）。范围是工作区中的所有更改。
2. 指定范围（“提交身份验证修复”、路径列表）。范围是与之匹配的更改。
3. 本次会话的文件集。 范围是本次会话中通过任何工具创建、编辑、删除或重命名的所有路径。包括你执行的命令在工作过程中更改的文件，例如依赖项安装所产生的锁文件，或代码生成器的输出。
4. 没有本次会话的文件集，因为会话刚开始，或工作已不在你的上下文中。停止操作，列出已更改的路径，并询问要提交哪些路径。说明可以使用 /commitkit all 来处理全部更改。

范围之外的路径不得处理。 将这些路径记录为范围外列表。绝不要暂存、提交、还原或丢弃其中的路径。其他会话已经暂存的路径应通过将工作分成多个提交中的保留暂存集继续保持已暂存状态。

本次会话中的路径可能包含你未编写的代码块，例如其他会话编辑了同一个文件。如果其状态显示的更改多于你所做的，或你知道其他会话也在处理该文件，请阅读其 diff。只提交你自己的代码块，并像提交每个分组中处理混合文件那样，以补丁形式暂存。如果代码块相互重叠，无法拆分，则停止并询问用户。

在基准分支上

通过问题分支和拉取请求协作的仓库，不希望直接向基准分支提交，因此在该分支上运行时会先询问。每天都向基准分支提交的个人仓库则不会收到询问。在提交每个组中的提交链之前运行此检查，并且仅当 HEAD 是基准分支时才运行。gitkit 负责管理基准分支；没有 gitkit 时，使用 git symbolic-ref --short refs/remotes/origin/HEAD 指定的分支，去掉 origin/。

如果用户已为本次运行指定分支（“在 main 上提交”、“放到 hotfix 分支上”），或调用技能传入了 no-push，则跳过检查。调用方负责管理自己的分支。

一次调用读取工作流信号：

git worktree list --porcelain | grep -E '^branch refs/heads/(issue|hotfix)-'; \
gh pr list --state merged --limit 1 --json number -q '.[].number' 2>/dev/null; \
gh api "repos/{owner}/{repo}/branches/<base>/protection" >/dev/null 2>&1 && echo protected

任何输出都代表一个信号：issue-* 或 hotfix-* 工作树、已合并的拉取请求，或受保护的基准分支。gh 执行失败视为没有信号。没有信号时，照常在基准分支上提交并推送。

有信号时，只询问一次本次运行的整体安排，并等待用户回答。 提供三个选项，并建议修复使用 hotfix-*，其他情况使用 issue-*：

• 在基准分支上提交。 按原样执行提交链。
• 使用 hotfix-<slug> 分支。 从问题症状提取 slug，采用 kebab-case，长度最多约 40 个字符，使用连字符，且绝不包含斜杠。在提交链开头加入 git switch -c hotfix-<slug> && \。
• 使用 issue-<n>-<slug> 分支。 先创建问题：gh issue create --title "<type(scope): summary of the main group>" --body "<one-line why>"，并从输出的 URL 中读取 <n>。不要添加 ready 标签，因为工作已经开始。从标题中去掉 type(scope): 前缀后提取 slug，采用 kebab-case，长度最多约 50 个字符。在提交链开头加入 git switch -c issue-<n>-<slug> && \，并在每条提交信息末尾添加 Refs #<n>。没有 gh 时，移除此选项。

新分支会带上工作树，包括范围外的更改，这些更改仍保持未提交状态。推送后，本次运行仍停留在新分支上。绝不要编造其他前缀的分支名。

完成条件： 本次运行位于用户选择的分支上；或者信号调用没有输出，且本次运行仍位于基准分支上。

仅生成提交信息的流程

用户在进行中的会话里只需要提交信息，不需要提交。此流程只读取并打印内容。索引、引用和远程仓库都保持原样。

1. 一次调用记录初始状态：git status --short && git rev-parse HEAD && git diff --cached --binary | git hash-object --stdin && git for-each-ref | git hash-object --stdin。不带 -w 的 hash-object 不会写入任何内容。
2. 确定主题。暂存区非空时，以暂存内容为主题，因此读取 git diff --cached。没有暂存内容时，以范围为主题，因此读取 git diff HEAD -- <scope paths>；若范围为 all，则读取不带路径的 git diff HEAD。适用读取状态中的读取限制。
3. 按照根据差异确定类型和范围和编写提交信息执行。为该主题编写一条提交信息。如果主题明显包含多个关注点，则每组各编写一条提交信息，并注明每组涉及的路径。
4. 在代码块中打印每条提交信息。

此流程中唯一允许使用的 git 命令均为读取操作：status、diff、log、rev-parse、for-each-ref，以及不带 -w 的 hash-object。

完成条件： 打印所有提交信息，并在结束时再次运行记录命令，确认提交和两个哈希与初始记录相同。用一行完成交接：说明没有任何更改，并指出下一步是使用这些提交信息进行“提交”。

Review 标记

提交后留待审阅的文档会附带一行标记，方便后续会话用一次 grep 找到它们。statuskit 会列出待处理的文档；如果没有 statuskit，可以用 grep -rl '^Review: pending' docs/ 列出。标记为 Review: pending，用户审阅文档后，将其替换为 Review: done YYYY-MM-DD。仅发送消息的处理方式和 Draft 模式都不会编辑文件，因此不会添加标记。

添加标记。 用户要求提交并推迟审阅（“提交计划和研究文件，我们稍后审阅”）。在读取状态之前，为请求中点名的 docs/ 下每个范围内的 Markdown 文件添加标记；如果请求提到了文件类型，则为 docs/plans/ 和 docs/research/ 下相应的文件添加标记。将该行作为单独的段落，放在标题块之后、第一个 ## 标题之前。若文件有 YAML frontmatter，则将其放在标题之后。已有 Review: 行的文件应替换该行，而不是另加一行。请求未涵盖的文件不添加标记。标记与文件一同提交，提交消息中不提及标记。

标记为已审阅。 用户表示文档已审阅（“我审阅了 verifykit 计划”“全部标记为已审阅”）。找到点名的文档；若用户说“全部”，则找到 docs/ 下每个带有 Review: pending 的文档。将该行替换为 Review: done 和当天日期。范围仅限这些文件，并通过常规流程提交，通常作为一个 docs 提交。被点名的文档若没有待处理标记，则添加一行说明，不做修改。

完成条件：所有涵盖的文件都恰好包含一行处于新状态的 Review: 标记，且该标记位于提交链开始之前。

Draft 模式

进入条件，且必须同时满足两项：调用者指定 Draft 模式，并且暂存的差异在提示中通过 <staged-diff> 标签提供，且你无法使用任何工具。lazygit 自定义命令等 Git 工具会驱动此模式：它会内联此文件，附加差异和任何辅助上下文，捕获你的标准输出，并将文本直接写入提交面板。你输出的任何非提交消息文字都会破坏提交。

Draft 模式取代范围、读取状态、将工作分成多个提交、提交每个分组和交接。根据差异确定类型和范围及编写消息仍照常适用，因此范围仍为必填项，正文仍为必需内容。

• 为整个暂存集合只编写一条提交消息。 此处不适用多提交的默认规则，因为暂存由调用者负责，而你无法重新暂存任何内容。
• 只输出原始消息，不要输出其他内容：主题行、一个空行，然后是正文。不要加前言、代码围栏、汇总表、交接内容、后续操作、Co-authored-by 或工具宣传。输出的第一个字符必须是主题的第一个字符。
• 通读整个负载以了解仓库上下文。 其中可能包含 git log --oneline 的输出。根据备注中的仓库惯例规则，匹配这些主题的风格。
• 预期会出现 [diff truncated] 标记。 根据差异的可见部分编写消息。提交中不要包含截断标记。
• 没有差异，就不输出。 如果负载中没有差异，则不输出任何内容并停止。

Draft 模式的优先级高于备注中的代码块回退方案。代码围栏用于方便人类手动复制消息；提交面板需要的是不带修饰的原始消息。

流程

1. 读取状态

从文件级变更概览开始，而不是完整差异，并在一次调用中完成：

git status --short && git diff --stat HEAD && git diff --cached --no-renames --name-only   # tree state, one line per file, the staged set

记录已暂存的文件集合。 最后一条命令会列出你开始操作前已暂存的所有路径。整个过程中都保留这份列表，因为 git add 只会向暂存区添加内容：之前已暂存的路径会随之进入下一次提交，除非你有意将其排除。若路径在 git status --short 中显示为 MM，则表示它是部分暂存的。用户暂存了其中一些代码块，留下了其余部分，因此提交组应采用其已暂存的代码块；除非用户明确要求，否则绝不能重新暂存整个路径。

本技能中的所有 git 调用都按相同方式批处理。 此技能会在会话结束时运行，此时上下文窗口最大，而每次额外的 Bash 调用都会再次将整个窗口作为输入付费。命令之间没有需要判断的环节时，用 && 串联；只有必须在两条命令之间停下来思考时，才单独调用。

接着，通过判断这些变更由谁编写，决定实际需要查看多少差异。

• 由你在当前上下文中编写（典型的编码会话交接）。你已经了解变更做了什么，更重要的是，了解为什么这么做：差异无法说明被否决的方案、中途发现 bug 的测试，以及你有意未修改的文件。根据统计信息进行分组，并根据你掌握的信息撰写提交说明正文。只在文件并非由你修改，或你确实记不清提交了什么时，才查看差异。
• 并非由你编写。 范围是 all，或指定范围延伸到了你自己的编辑之外；你是作为子 Agent 被派遣的；或者工作发生得太久远，已不在当前上下文中。那么差异就是你唯一的信息来源，但要按组查看，绝不可一次查看全部。先根据统计信息勾勒分组，再用 git diff HEAD -- <paths> 查看每组的差异；一旦明确该组的类型、范围和效果，就停止查看。无路径参数的 git diff HEAD 会一次性将整个会话的变更加载到上下文中；逐组查看则能将每次读取限制在你正在撰写说明的那一组内。

拿不准时，就查看差异。模糊的提交说明造成的代价，高于节省的 token。但重新阅读几分钟前由你编写的代码毫无意义：统计信息已能说明哪些文件发生了变化，而且你已了解自己对它们做了什么。

无论采用哪种方式，都绝不读取生成文件的内容，包括锁文件（*.lock、package-lock.json、pnpm-lock.yaml、go.sum）、构建产物、供应商目录、快照和编译后的资源文件。它们的统计行已包含提交说明所需的全部信息，而且在大多数代码仓库中，它们的差异最大。

• 用户已委托你进行提交时（典型的编码会话指令，如“commit”或“提交我的更改”），你可以自行暂存所需文件，因此每次提交逻辑分组时，用 git add 添加相应路径即可。无需事先询问；分组和暂存是你的职责。
• 只有在意图确实不明确时才暂停询问，例如工作区中有未完成的工作、机密信息、你怀疑用户无意提交的变更，或者某个文件部分暂存，而重新暂存整个路径会包含用户有意留在暂存区之外的代码块。绝不要盲目地对无关内容执行 git add -A；应按组暂存（参见将工作分成多个提交）。
• 如果用户要求进行一次特定的提交，就遵照要求，不要自动拆分。
• 如果范围内没有变更，就停止并说明情况。如果工作区中存在范围外的变更，也要指出。

完成标准： 已确定的范围及其路径列表、变更路径列表、标明部分暂存路径的已暂存文件记录，以及对变更编写者的判断。

2. 根据差异确定类型和范围

根据差异实际做了什么来选择 type，而不是根据改动了哪些文件：

type	适用情况
feat	新增用户可见的功能
fix	修复 bug
hotfix	直接在基准分支上紧急修复
docs	仅修改文档
refactor	不改变行为的代码修改
perf	性能改进
test	添加或修复测试
build / ci	构建系统、依赖项或流水线
style	格式或空白字符调整，不涉及逻辑
chore	不属于以上类别的日常维护

hotfix 是仓促修复的 fix；由分支决定，而非严重程度。 当提交位于从基准分支切出、用于直接修补问题的 hotfix-<slug> 命名分支上时，使用 hotfix。其他情况一律使用 fix，无论问题当时有多紧急。这样便可以根据分支名检查类型，而不是依靠对 bug 严重程度的判断。hotfix 是对 Conventional Commits 类型集合的补充，因此在工具会根据标准列表验证类型的仓库中，应改用 fix，并说明一次这样做的原因。

这里必须填写范围。 与原版 Conventional Commits 不同，绝不能省略范围。确定差异所属的模块或功能组（软件包、模块、目录或功能区），并将其用作范围：feat(auth): …。如果改动确实是全局性的，或不属于任何单一区域（整个仓库的配置、工具、跨领域清理），则使用 repo 作为范围：chore(repo): …。如果改动会破坏现有行为，添加 !（或 BREAKING CHANGE: 页脚）。

完成标准： 每个计划的提交都恰好有一个类型和一个范围。

3. 编写提交信息

格式：

type(scope): short imperative summary

one-line summary of why the change was made

- reason/change bullet
- reason/change bullet

Reference issues in a footer.

(scope) 为必填项，因此每条提交信息都必须带有范围；全局改动使用 (repo)。

规则：

• 使用祈使语气，主题全部小写。首词和标题中的任何词都不得大写（专有名词和缩写除外），结尾不得加句号，并尽量控制在 50 个字符以内。
• 摘要应说明改动的效果（“为 fetch 客户端添加重试”），而不是改动的操作（“修改 fetch 客户端”）。
• 正文每行不得超过 72 个字符。 将较长的项目符号条目拆成两条，或在下一行缩进续写。commitlint 等提交钩子的 body-max-line-length 规则会拒绝过长的行；72 个字符符合常见的 72、80、100 字符限制。
• 必须包含正文。 先用一句简短的话说明原因，然后列出原因和具体改动。仅保留评审者需要的信息。简单的提交无需赘述，但始终要包含摘要行和至少一个项目符号。
• 除非用户要求，否则不要添加 Co-authored-by 或工具宣传内容。

完成标准： 每条提交信息都必须包含带范围的小写祈使句主题、一行原因说明和至少一个项目符号，并且正文每行不得超过 72 个字符。

4. 将工作分成多个提交

提交任何内容之前，先将更改划分为逻辑组。每个功能组或相关工作单元（功能及其测试、错误修复、文档更新、重构、配置更新）都应成为单独的提交。这是默认做法，不是例外：一次会话涉及三个方面，就应生成三个各有范围的提交。

按更改实现的目标分组，而不是按文件类型或目录分组。将功能与其相关的测试和文档放在一起，不要拆分到不同提交中。也不要过度拆分；一项连贯的更改即使涉及多个文件，也应作为一个提交。

按依赖关系排列各组，让依赖项先提交（例如，先提交共享辅助函数，再提交使用它的功能）。如果一个文件包含属于多个组的差异块，就计划以交互方式暂存，而不是将整个路径分配给某一组。

将记录的暂存集中的每个路径都纳入安排。 Scope 范围内预先暂存的路径归入所属组。范围外预先暂存的路径不归入任何组，并在运行结束后继续保持暂存状态。将这些路径列为保持暂存集。

**完成条件：**每个范围内的已更改路径恰好属于一个组或列入明确的跳过列表；每个范围外路径都列入范围外列表；每个记录的暂存路径都属于某个组或保持暂存集。

5. 提交每个组

当 HEAD 位于基础分支时，先按照位于基础分支处理分支。在所有组和提交消息都已规划好的情况下，在一次 Bash 调用中暂存并提交所有组，使用 && 连接命令，并以推送和交接所需的 git status -sb 结束命令链。每次提交前，检查暂存集是否恰好等于该组的路径，确保提交不会包含属于其他组的路径：

git add -- <group 1 paths> && \
test "$(git diff --cached --no-renames --name-only | sort)" = "$(printf '%s\n' <group 1 paths> | sort)" && \
git commit -m "type(scope): summary" -m "why in one line

- reason/change bullet
- reason/change bullet" && \
git add -- <group 2 paths> && \
test "$(git diff --cached --no-renames --name-only | sort)" = "$(printf '%s\n' <group 2 paths> | sort)" && \
git commit -m "type(scope): summary" -m "why in one line

- reason/change bullet" && \
git push -u origin HEAD && git status -sb && \
gh pr view --json number,url,state 2>/dev/null || true

在每次 git add、git diff、git restore 和 printf 调用中，都要逐字写出每个路径。不要将路径列表存入 shell 变量，例如 g2="a b c"，因为 zsh（macOS 的默认 shell）不会将未加引号的变量拆分为多个单词：git add -- $g2 会将 a b c 作为一个路径，并因此失败。路径中含有空格时，请将其括起来。

在最后一次提交之后，使用 && 将推送加入命令链，这样任何组中的添加、检查或提交失败都会中止命令链，不会部分发布。下方暂存路径转存模式中的 ; 是唯一例外，转存的组不会执行推送；应在所有提交都完成后，单独调用推送命令。

不要将部分暂存的路径放入 git add，并将其保留在检查清单中，以便该组只提交已暂存的差异块。重命名文件的两侧路径都要列入其所属组，因为 --no-renames 会显示旧路径和新路径。

**将不属于当前组的已暂存路径转存。**如果记录的暂存集包含当前组以外的路径（保持暂存路径或后续组的路径），检查就会失败，直到这些路径离开索引。将它们作为补丁移出，提交该组，再将它们恢复：

park="$(git rev-parse --git-path commitkit-park.patch)"
git diff --cached --binary --no-renames -- <other staged paths> > "$park" && \
git restore --staged -- <other staged paths> && \
git add -- <group paths> && \
test "$(git diff --cached --no-renames --name-only | sort)" = "$(printf '%s\n' <group paths> | sort)" && \
git commit -m "type(scope): summary" -m "…"; \
git apply --cached "$park"

补丁会保留已暂存差异块的原样，因此，部分暂存的文件恢复后仍是部分暂存状态；已暂存的新文件或删除操作也会恢复为已暂存状态。git commit -- <paths> 更简短，但它会提交每个路径在工作树中的副本，从而将部分暂存文件中尚未暂存的差异块也带入提交。检查或提交失败时，git apply 仍会通过前面的 ; 恢复转存的路径。由于 ; 也会让命令链在提交失败后继续运行，因此每个转存的组都要单独调用；只有确认该组已成功提交后，才能开始下一个组。如果 git apply --cached 失败，请停止并报告补丁路径，因为转存的差异块就在该文件中。

gh pr view 的末尾命令会告知接手者该分支是否已有拉取请求。它无需额外成本，因为与其他命令在同一次调用中运行。结果为空或 gh 执行失败都表示没有拉取请求，这是正常情况，不是错误。 当推送只是向 origin 快进时，默认推送。 只存在于这台机器上的提交，一个磁盘故障就会丢失，而用户几乎每次都会选择发布提交。如果仓库有 origin 远程，且分支跟踪 origin 或根本没有上游分支，就推送。分支名称不影响这一点；主题分支和基分支的推送方式相同，因为许多个人仓库会直接在基分支上提交，如果在那里提示，就会在每次运行时触发。采用分支工作流的仓库会在提交前询问要使用哪个分支，详见在基分支上，而不是在推送前询问。

遇到以下情况时，暂停推送并询问：

• 远程拒绝了推送。 报告拒绝原因并停止。此时绝不要使用 --force 或 --force-with-lease；推送被拒绝意味着远程上的分支已发生变化，重写分支是 gitkit 和 prkit 的职责，不是 commitkit 的。
• 没有 origin， 或分支跟踪的是其他远程。报告提交，并说明用户应运行的推送命令。

如果用户或调用技能要求 no-push，则跳过推送（“只提交，不要推送”“提交，但别推送”“暂时不要发布”）。从命令链中删去 git push -u origin HEAD，保留 git status -sb，并说明提交仍在本地。传入 no-push 的调用技能负责推送：例如 afkkit 会在 prkit 创建 PR 时发布一次分支。

对混合文件进行交互式暂存（见将工作分成多个提交）是唯一无法加入命令链的步骤。先在一次调用中提交该组之前的内容，处理拆分，然后再将其余步骤串联起来。

用户委托了提交（“提交”“提交我的更改”）时，每组都直接照此处理，无需逐次确认。仅要求提供提交消息的请求不会到达这一步；它会在仅消息流程结束。如果提交失败（例如，提交前钩子拒绝提交），&& 命令链会在失败的分组处停止，后续分组仍未提交；因此应显示钩子输出，修复问题或向用户询问，然后从该分组恢复命令链。不要盲目重试，也不要使用 --no-verify 绕过钩子，除非用户明确要求。

完成条件： git log --stat 中每个提交的文件列表都与其分组路径一致；运行后保留的暂存文件集与应保留暂存的文件集一致；所有范围外路径的 git status --short 行都与开始时相同；并且推送已执行，或已记录暂停推送的理由。

6. 移交

本节采用步骤式语气：每句话只给出一条指令，使用主动语态和现在时，不使用比喻。

用变更内容、提交所在位置和下一步行动作为结尾。

变更内容。 打印所创建提交的摘要表，让用户一目了然地看到结果：

#	提交消息	文件
1	feat(auth): add token refresh retry	auth/token.ts、auth/token.test.ts
2	chore(repo): bump ci node version	.github/workflows/ci.yml

在最后一列列出每个提交中已修改或已创建的文件。你已经知道这些文件，因为它们是你为每组传给 git add 的路径，所以请据此构建表格，而不要再次查询 git。如果确实需要检查，一个 git log --stat --oneline -<n> 就能涵盖你刚创建的所有提交；不要针对每个提交单独运行 git show。如果某个提交涉及很多文件，请列出关键文件并添加“+N 个文件”。如果还有未提交的内容（有意跳过、留给用户处理或有意保持暂存状态），请在表格下方注明。用一行列出范围外的路径，让用户知道本次运行将哪些变更留给后续会话或 /commitkit all 处理。

提交位置。 报告提交所在的分支，并说明是否已推送。提交链末尾的 git status -sb 会在一行中显示分支及其上游；请根据该输出报告，而不要再次运行该命令。如果没有推送，请说明这一点并列出原因，因为仅存在于这台机器上的提交是报告中最重要的内容。

下一步。 只指定一项行动，然后停止。根据你已读取的状态，按以下顺序选择：

1. 调用方技能传入了 no-push。 报告提交并返回调用方。下一步由调用方负责，因此不要指定其他行动。
2. 未执行推送。 将推送作为下一步，并提供命令。
3. 本次运行将文档标记为 Review: pending。 将审核作为下一步：列出每个已标记的文件，并说“阅读后告诉 commitkit 你已审核”。仅文档的运行不要指定创建拉取请求。
4. 该分支已有未关闭的拉取请求（gh pr view 的最后输出显示了一个拉取请求）。这些提交现已进入该拉取请求，因此应指定审核，而不是新建拉取请求。说明拉取请求已更新，提供其编号和 URL，并根据提交原因指定相应行动。修复审核意见后，应使用 mergekit 回复审核者并重新请求审核；否则使用 gh pr comment <number>。不要为已有拉取请求的分支指定新建拉取请求。
5. 拉取请求已合并或已关闭。 说明这一点，并指定使用 gitkit 为这项工作创建新分支；否则使用 git switch -c <name> <base>。
6. 该分支没有拉取请求。 指定仅用这些提交创建拉取请求：已安装 prkit 时使用它，否则使用 gh pr create。
7. 功能显然尚未完成。 说明这一点，并指定直接继续构建，然后重新运行 commitkit 处理下一组内容。

不要自行创建拉取请求；commitkit 的工作在推送后结束。

完成条件： 表格列出每个提交，分支行说明是否已推送，并且只指定一项下一步行动；或者报告返回给调用技能。

备注

• 绝不要运行 git commit --amend、git rebase、git reset 或任何其他改写历史的命令，除非用户明确要求。快进推送会发布工作，并且可以通过还原恢复；而改写已发布的分支无法恢复，因此这里设置了这项限制，而不是限制推送（参见提交每组内容）。
• 如果仓库有自己的提交规范（例如 CONTRIBUTING.md、提交模板或 git log 中明显不同的风格），请优先遵循该规范，而不是这些默认规则，并说明你已这样做。
• 如果无法访问文件系统或 Shell，就不能运行 git。此时请阅读用户提供的差异，并将最终提交消息放在代码块中，供用户自行运行。