在 DevAgent 中提交与推送
你可以在不离开 DevAgent 的情况下完成提交、推送并打开评审。提交面板就在 diff 查看器旁边，专为最常见的场景而设计——审查、暂存、提交、推送、继续下一件事。
提交
- 从 diff 中按 hunk 或按文件暂存改动。
- 在底部面板中撰写 commit message，或者在你希望 DevAgent 根据已暂存的改动起草一条时使用 Generate with AI。
- 当焦点位于 Source Control 且主操作为 Commit 时，按 Commit（macOS 上为
Cmd-Enter，Windows / Linux 上为Ctrl-Enter）。
仓库中的 pre-commit hook 会照常运行。如果某个 hook 失败，DevAgent 会在行内展示其输出。
当提交失败时，可以从失败详情中使用 Fix with AI，它会在当前活跃的 worktree 中启动默认 agent，并附上 hook 输出、尝试过的 commit message 以及已暂存文件列表。agent 只会收到一个修复用的 prompt——它不会被要求绕过 hook、提交、推送或打开评审。
推送
Push 会把 worktree 的分支推送到 origin，并在首次推送时设置 upstream。如果分支落后于远程，DevAgent 不会悄悄地强制推送。
当你重写了历史（rebase、amend、squash），而远程只有你本地 commit 的旧副本时，Source Control 面板会把 Force push with lease 作为一个明确、独立的操作展示出来——绝不会把它当作普通 Push 的兜底方案。标签上会显示将被替换的 commit 数量以及 upstream 分支名，让你清楚地知道即将发生什么变化。强制推送使用 --force-with-lease，因此当你对远程的本地视图已经过期时，推送会中止，而不会覆盖掉别人的 commit。
打开托管评审
分支推送之后，使用 Source Control 面板的托管评审操作来创建 pull request 或 merge request。在提交之前确认 base 分支、标题、描述以及 draft 状态。Bitbucket Cloud 也可以从同一个撰写器创建 pull request；它没有 draft PR，因此 Draft 选项会被隐藏。对于 GitHub，当所选的 base 上已经有一个打开的 PR 时，你可以 Stack this PR above #N——参见 堆叠式 pull request。
如果 DevAgent 需要在 Create PR 流程中运行一个后续 commit，而该 commit 失败了——hook 拒绝了它，或者工作树处于无法提交的状态——对话框会展示一份详尽的失败摘要，附上 hook 输出和后续操作按钮，而不会把你直接丢回面板、让你毫无头绪。可以从摘要中使用 Fix with AI 把失败交给 agent 处理，或者自己解决后重新运行。
当你希望 DevAgent 根据分支 diff 和 commit 起草标题、描述以及 draft 状态时，可以在创建评审的对话框中使用 Generate pull request details with AI。生成的文案力求写出简短、通俗易懂（ELI5）的问题/解决方案小节，并给出关联 issue 的建议（当附加了 GitHub issue 时区分使用 Fixes 与 Refs）。DevAgent 会保留你所选的 base 分支，拒绝空描述，并抛出清晰的错误让你重试，而不是交付一个空白正文。在创建评审之前请检查这些字段。
每个仓库的 AI 操作 recipe
Generate with AI、Generate pull request details with AI、Fix with AI 和 Resolve with AI 都是 Source Control 的 AI 操作——每一个都由一份 action recipe 支撑，它决定了当你触发该操作时 DevAgent 所运行的 agent、CLI 参数和 prompt 模板。你可以在 设置 → Git → Action recipes 中编辑它们，既可以作为全局默认值，也可以限定到当前仓库。
模板中可以包含各种变量，比如用于 commit message 的 {basePrompt}、{branch}、{stagedFiles}、{stagedPatch} 和 {linkedIssue}；PR details 还额外支持 {baseBranch}、{currentTitle}、{currentBody}、{commitSummary}、{changedFiles} 和 {patch}。
{linkedIssue} 会展开为与该 workspace 关联的 GitHub issue 编号，若没有关联则为空（包括纯 Linear/GitLab 的 workspace）。建议采用指令式的表述——一个裸的 Fixes #{linkedIssue} 在未关联时会变成 Fixes #。
当某个仓库为某项操作拥有自己的 recipe 时，保存对全局默认值的更改并不会触及它——设置面板会展示一条 Repository overrides 提示，列出哪些仓库有分歧、它们覆盖了什么（agent、CLI 参数或命令模板），并提供一个 Review 链接跳转到该仓库的设置，让你可以更新或移除这个覆盖。
修补（Amend）
修补是显式操作——Commit → Amend。除非你确认，否则 DevAgent 不会修补已经推送过的 commit。
Source control 面板
侧边栏的 Source Control 面板让你无需离开当前视图就能使用这些相同的操作：暂存和丢弃文件、撰写 commit message，以及把 Commit、Push、Pull 或 Sync 作为一键操作运行。即便路径中包含非 ASCII 字符，也会以 UTF-8 渲染。
顶部的分支上下文行显示当前分支（或 detached HEAD），并将其叠放在对比 base 之上（branch → base），这样 Create PR 和远程操作就永远不会遮住你所在的分支。当分支有一个可用的 merge base 时，一个紧凑的小标签会显示相对该分叉点的总新增和删除行数（一次范围 diff，而非把已暂存/未暂存区域相加）。当主机发布了拆分数据时，将鼠标悬停在该小标签上可看到 Code breakdown：Source、Tests 和 Generated（Generated 仅在非零时显示）——这只是基于路径的启发式判断，而非内容分析。过长的分支名会被截断，以免遮住小标签。
右键点击一个已改动的文件可使用 Copy Path / Copy Relative Path（相对于 worktree 根目录）。
面板底部的主按钮会随状态变化，让下一个有用的操作始终触手可及：当有未暂存的改动时是 Stage Files，然后是 Commit，接着根据分支相对其 upstream 的状态显示 Push / Pull / Sync。
当 merge、rebase、cherry-pick 或 revert 留下冲突时，Source Control 会在 Review conflicts 旁边显示 Resolve with AI，让你既可以把这组冲突交给 agent，也可以在继续之前自己检查。对于一个你不想再进行的 merge 或 rebase，可以从 Source Control 使用 Abort merge 或 Abort rebase。
下一步
- 托管评审、issue 与 Actions——连接拥有该评审的 provider。
- Annotate AI Diff——在提交前留下行内批注。