文档 / 审查 / 托管审查、问题与 Actions

托管代码评审是 worktree 的一等公民功能。Orca 将 worktree 与其拉取请求或合并请求关联起来，内联展示评审状态，让你无需离开应用即可分类处理 issue。

连接提供商¶

在 设置 → 集成 中连接你的仓库所使用的提供商。GitHub 提供最深入的 Actions 与 issue 支持；GitLab 合并请求和 issue 使用相同的 worktree 评审流程。

Bitbucket Cloud 可在同一面板内直接连接 —— 使用 Email 和 API 令牌或访问令牌进行连接。Orca 在保存前会验证凭据，并且可以从 Source Control 创建拉取请求。Bitbucket Cloud 不支持草稿 PR，因此编辑器会隐藏草稿开关。ORCA_BITBUCKET_* 环境变量仍然优先于已保存的凭据。Azure DevOps 和 Gitea 的拉取请求会与 GitHub、GitLab、Bitbucket 一起出现在 worktree 侧边栏和 Checks 面板中 —— worktree 创建流程会在推送前检查它们是否存在远程冲突。

评审¶

• 在 worktree 已推送后，从 Source Control 面板打开托管评审 —— 创建前确认基础分支、标题、描述和草稿状态。
• 在你创建或打开托管评审时，Source Control 会在分支上下文行中保持当前分支可见，因此“创建 PR”操作永远不会替换分支标签。
• 关联的评审会显示在侧边栏中并带有状态，因此你可以区分该分支是仍是打开、已合并还是已关闭。
• 当 Orca 拥有关联 PR / MR 的 URL 时，分支上下文行会显示一个紧凑的在浏览器中打开评审页面链接 —— 一键即可跳转到 GitHub、GitLab、Bitbucket、Azure DevOps 或 Gitea 上的评审，而无需打开内部 PR 视图。
• 对于 GitHub 拉取请求，使用侧边栏中的 PR 操作菜单可以复制评审链接、关闭评审，或在确认状态变更后重新打开评审。
• GitHub 的 checks、评审和评论会在 PR 标签页内联打开；GitLab 的合并请求和 issue 会在同一评审界面中打开。
• 对于 GitLab 流水线，Checks 侧面板会包含 bridge 和子流水线作业（不仅仅是顶层作业）。展开某个作业会在可用时加载该作业的 trace（日志）——与 GitHub check 详情打开的位置相同 —— 因此失败的作业不会是“没有内联详情”的死胡同占位。
• 在 Checks 面板中，你可以回复评审线程中的任意评论，而不仅仅是根评论。
• GitHub PR 对话评论和内联评审线程评论都有与 GitHub 八种反应匹配的表情选择器（👍 👎 😄 😕 ❤️ 🎉 🚀 👀）。已有的表情块是开关。GitLab 评论保持不变。
• 分组的 PR 评论区块按最新优先排序，因此新回复会将其线程顶到最上方。时间线标签页仍保持最早优先。
• 当 GitHub 拉取请求有失败的 checks 时，使用 PR 视图中的修复损坏的 checks 将失败的 check 名称和链接交给 agent。

自动合并¶

对于处于打开状态的 GitHub PR，PR 视图的合并按钮会提供启用自动合并，一旦其要求（checks、必需的评审）通过，GitHub 就会自动合并该分支。合并方式遵循仓库的默认设置，为 Squash 并合并、创建合并提交或 Rebase 并合并之一 —— 仓库不允许的方式不会显示。使用同一控件中的禁用自动合并可取消待定的自动合并。当基础分支使用 GitHub 的合并队列时，同一控件会显示为准备好时合并，并将 PR 加入队列。对于 GitHub 报告为草稿、已关闭、存在冲突或不稳定的 PR，以及不允许自动合并的仓库，自动合并控件会隐藏 —— 在这些情况下，你只会看到手动合并操作。

堆叠式拉取请求¶

当你创建 GitHub 拉取请求，且所选基础分支已有一个打开的 PR 时，编辑器会提供将此 PR 堆叠在 #N 之上。勾选后会创建一个 GitHub Stack（或扩展父级已有的 stack），并将提交标签改为在 stack 中创建 PR（或在 stack 中创建草稿 PR / 推送并在 stack 中创建 PR）。小预览会显示父 PR 和新分支。该选项仅限 GitHub，且只在执行环境支持 stack 创建时显示。GitLab 合并请求和 Bitbucket 拉取请求仍保持单 PR 创建。

当 GitHub 将拉取请求注册为 stack 的一部分时，PR 侧边栏会显示一个可折叠的 Stack #N 图示：你在 stack 中的位置、stack 大小以及 stack 基础分支。展开后可以看到有序的各层及其状态（打开、草稿、checks 待定/失败、需要评审、冲突、已合并、已关闭）。点击某一层即可在 Orca 中打开该 PR。

支持 stack 的合并会用合并至 #N · 共 M 个 PR（或在仓库使用合并队列时显示排队至 #N · 共 M 个 PR）替换单 PR 合并标签。该操作会覆盖当前 PR 以及 stack 中它下方的所有 PR。当 stack 元数据完整时，确认信息会列出包含的编号。原子 stack 合并采用失败即关闭 —— 如果任何一层无法合并，则全部不合并。没有 GitHub 注册的 stack 元数据的普通关联 PR 链仍保持常规的单 PR 合并流程。GitLab 合并请求保持不变。

Issue¶

issue 抽屉让你可以在 Orca 中浏览、筛选和编辑 GitHub 与 GitLab 的 issue。从 GitHub issue 或 PR 创建 worktree 会打开交互式工作区编辑器（而不是静默的后台创建），因此 issue 命令自动化、SSH 目标和文件夹工作区与其它创建路径的行为一致。编辑器会预填任务名称并关联 issue，以便评审保持与任务关联。

对于 GitHub issue，详情对话框有一个活动区块，将评论和时间线事件交错显示 —— 分配、提及、交叉引用、状态变更和项目列移动 —— 因此你无需离开 Orca 即可查看完整历史。

使用工作区侧边栏中的关联 issue 菜单即可复制 issue 链接，无需打开抽屉。

对于 GitLab 仓库，抽屉会列出所选项目中打开的 issue，并可将列表缩小到指派给你的 issue。

操作¶

失败的 GitHub Actions 检查会以红色 chip 显示在 worktree 上。点击即可内联查看失败作业的日志。

任务¶

Orca 在 Tasks 侧边栏条目下展示完整的 GitHub Projects 视图——浏览跨仓库的项目卡片，按源仓库筛选，查看草稿 pull request 状态，并从任意卡片创建 worktree。

故障排除¶

如果 PR 状态、检查或 Tasks 无法刷新——速率限制、gh 身份验证、权限或网络——请参阅 GitHub 错误故障排除。

后续步骤¶

• 从 Orca 提交并推送 — 暂存更改，推送分支，然后创建托管审查。
• Linear 事项抽屉 — 当任务来源位于 git 提供商之外时，使用 Linear。
• GitHub 错误故障排除 — 速率限制、身份验证和 gh 故障。