跳转至

文档 / 审查 / 从 Orca 提交并推送

你可以在不离开 Orca 的情况下提交、推送并发起评审。提交面板位于 diff 查看器旁边，专为常见场景设计——评审、暂存、提交、推送、继续前进。

提交

  1. 从 Source Control 面板暂存变更的文件。
  2. 在底部面板编写提交信息，或当你希望 Orca 根据已暂存的更改草拟提交信息时，使用 Generate with AI。
  3. 当焦点位于 Source Control 且主操作为 Commit 时，按下 Commit（macOS 为 Cmd-Enter，Windows / Linux 为 Ctrl-Enter）。

来自仓库的 pre-commit 钩子照常运行。如果钩子失败，Orca 会在内联区域显示相关输出。

提交失败时，可使用失败详情中的 Fix with AI，在活动工作树中启动默认 agent，并传入钩子输出、尝试提交的信息和已暂存文件列表。agent 只会收到修复提示——不会要求它绕过钩子、提交、推送或发起评审。

推送

Push 会将工作树的分支推送到 origin，并在首次推送时设置上游。如果分支落后，Orca 不会静默强制推送。

当你重写了历史（rebase、amend、squash），而远程只有你本地提交的旧副本时，Source Control 面板会将 Force push with lease 作为明确且独立的操作显示——绝不会作为普通 Push 的替代方案。该标签会显示将被替换的提交数量以及上游分支名称，以便你准确了解即将发生的变化。Force push 使用 --force-with-lease，因此如果你本地对远程的视图已过期，推送会中止，而不会覆盖他人的提交。

发起托管评审

推送分支后，使用 Source Control 面板的托管评审操作创建 pull request 或 merge request。提交前请确认基础分支、标题、描述和草稿状态。Bitbucket Cloud 可以使用同一个撰写界面创建 pull requests；它没有草稿 PR，因此 Draft 会被隐藏。对于 GitHub，当所选基础分支已有打开的 PR 时，你可以 Stack this PR above #N——参见堆叠的 pull requests。

如果 Orca 在 Create PR 流程中需要执行后续提交，而该提交失败——无论是因为钩子拒绝，还是工作树处于无法提交的状态——对话框会显示详细的失败摘要，包含钩子输出和后续步骤按钮，而不是将你无上下文地丢回面板。你可以使用摘要中的 Fix with AI 将失败交给 agent，或自行解决后重新运行。

当你希望 Orca 根据分支 diff 和提交来草拟标题、描述和草稿状态时，可在创建评审对话框中使用 Generate pull request details with AI。生成的文案力求简短，包含 ELI5 式问题/解决方案部分，以及关联 issue 的指引（当已关联 GitHub issue 时，区分 Fixes 与 Refs）。Orca 会保留你选择的基础分支，拒绝空描述，并显示清晰的错误，以便你重试而不是提交空内容。创建评审前请检查各字段。

按仓库的 AI 操作配方

Generate with AI、Generate pull request details with AI、Fix with AI 和 Resolve with AI 都是 Source Control 的 AI 操作——每个操作都由一个 action recipe 支撑，该配方会选择 agent、CLI 参数，以及你触发操作时 Orca 运行的提示模板。你可以在设置 → Git & Source Control → Action recipes 下编辑它们，既可以作为全局默认，也可以限定到当前仓库。

模板可以包含变量，例如提交信息的 {basePrompt}、{branch}、{stagedFiles}、{stagedPatch} 和 {linkedIssue}；PR 详情还支持 {baseBranch}、{currentTitle}、{currentBody}、{commitSummary}、{changedFiles} 和 {patch}。

{linkedIssue} 会展开为工作区关联的 GitHub issue 编号；当未关联时（包括纯 Linear/GitLab 工作区）则为空。建议使用说明性措辞——裸写 Fixes #{linkedIssue} 在未关联时会变成 Fixes #。

当某个仓库对某操作有自己的 recipe 时，保存对全局默认设置的更改不会影响它——设置窗格会显示 Repository overrides 提示，列出哪些仓库有差异以及它们覆盖了什么（agent、CLI 参数或命令模板），并附有 Review 链接，可直接跳转到该仓库的设置，以便你更新或移除覆盖。

修改提交

修改提交是显式操作——Commit → Amend。除非你确认，否则 Orca 不会修改已推送的提交。

Source Control 面板

侧边栏的 Source Control 面板可让你无需离开当前视图即可使用同样的操作：暂存和丢弃文件、编写提交信息，以及一键运行 Commit、Push、Pull 或 Sync。路径即使包含非 ASCII 字符也会以 UTF-8 渲染。

顶部的分支上下文行会在比较基准上方显示当前分支（或游离的 HEAD）（branch → base），因此 Create PR 和远程操作永远都不会隐藏你所在的分支。当分支有可用的合并基准时，一个紧凑的 chip 会显示相对于该分支点的新增和删除总行数（一个范围 diff，而不是暂存/未暂存区域的合计）。当托管平台发布拆分时，将鼠标悬停在该 chip 上可查看 Code breakdown：Source、Tests 和 Generated（仅在非零时显示 Generated）——仅基于路径启发式判断，而非内容分析。长分支名会被截断，以免覆盖 chip。

右键单击已更改的文件可使用 Copy Path / Copy Relative Path（相对于工作树根目录）。

面板底部的主按钮会随状态变化，因此下一个有用的操作总是只需一次点击：有未暂存更改时显示 Stage Files，然后是 Commit，之后根据分支与其上游的关系显示 Push / Pull / Sync。

当 merge、rebase、cherry-pick 或 revert 产生冲突时，Source Control 会在 Review conflicts 旁显示 Resolve with AI，你可以将冲突集合交给 agent，也可以自行检查后再继续。如果你不再需要正在进行的 merge 或 rebase，可从 Source Control 使用 Abort merge 或 Abort rebase。

后续步骤

本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 orca48/orca