end — 收工（提交、推送、合分支）

一次做完 Git 收尾：拉最新 → 提交本任务 → 推工作分支 → 切到合入分支同步 → 合并 → 推合入分支 → 回到工作分支。只动 Git：不归档 ralph 任务、不改调度记录、不写业务代码。归档过的任务想再改，去 ralph 同编号续做。

写法

工具	写法
Codex	`$jj-end`
Claude / Grok / Qoder	`/jj-end`

也可以直接说「收工」「合到 dev」「结束任务提交并合并」。

适用与边界

用得当：

功能改完了，要正式提交并推上去
多项目调度已经"验收通过"，但各仓还没 push、没合

别用在： 只想中途存一下（自己 git commit 就行）；只要审查（review）；不允许 push 的场合。

开始前

功能已改完且已验收——end 不负责功能验收
明确合入目标分支；未指定时按 dev → develop → main 顺序取第一个存在的
当前分支须为任务工作分支；end 在该分支上收工，不会自动切换分支

第一次这样用

你说：

text

$jj-end

Agent 会做：

先打印一行计划：工作分支 → 合入分支（来源：你指定 / 文档约定 / 默认规则），让你有机会当场拦住
git fetch，看清当前分支、有没有未提交改动、和远端差多少
只提交 这个任务的文件，中文提交信息（类型(范围): 说明）；无关的临时文件、本地转储不会被提交进去
同步远端工作分支（能快进就快进，否则合并），再推工作分支
切到合入分支，同步到最新，把工作分支合进来，再推
回到工作分支

固定 Git 步骤由随技能安装的脚本批量执行（先只读预览，核对文件和目标后在已有授权下执行）；若文件、分支或远程配置在执行前变化，会要求重新生成预览。未纳入本任务的脏文件会明确列出。

你会看到： 一行收工结果，例如 已合并：feat/dynamic-form → dev · 当前在 feat/dynamic-form。没有 commit hash 清单。

怎样算做完： 工作分支和合入分支都推到了远端。只推了工作分支不算收工。

常用说法

text

$jj-end
收工，合到 dev
$jj-end integration=staging
$jj-end dry_run=true

dry_run=true 只打印会做什么（工作分支、合入分支、会不会提交 / 合并 / 推送），不改仓库。合入预发必须写 integration=staging——git log 里的 Merge into staging、仓库里有 staging 分支、构建脚本名带 staging，都不算约定。

做完之后

情况	会怎样
做完实现，Agent 主动说要收工	设计内行为：实现完成且你没禁止推送时，它先打印一行计划再执行。不想推就明说「先别推」「只提交不推」
遇到合并冲突	先把冲突文件分类成表（`self-merge` / `unhandleable`）。能一句话说清如何合并、不用替产品做决定的，自行合完继续收工；真正无法合并的（同一开关两边相反、二进制 / 密钥）整段中止、回到工作分支，把表交给你。不会只解一半，也不会留下半成品合并
推送失败	停在工作分支，把远端的报错给你
想合进 staging / 预发	必须明说 `integration=staging`，或仓库文档写明收工分支是它

红线

不 force push、不删分支、不改 git 配置
不用 pull --rebase（除非你明确要求）
不把无关文件、临时脚本、密钥一起提交
只许工作分支合进 dev，禁止把 dev 合进功能分支
冲突默认自行合并：两边各自新增的行为都留下；禁止整文件 --ours/--theirs
合并中止不算成功；不会只推了工作分支就说"收工成功"
调度里显示「验收通过」不等于已经合进 dev

记录在哪

只在 Git 里：提交、分支、远端。end 不写任何任务文件。

end — 收工（提交、推送、合分支） ​

写法 ​

适用与边界 ​

开始前 ​

第一次这样用 ​

常用说法 ​

做完之后 ​

红线 ​

记录在哪 ​

相关 ​