第42章 托管代码评审、Issues 与 Actions 管理
worktree 推送后，可从 Source Control 面板打开托管评审——创建前确认基础分支、标题、描述和草稿状态。
创建或打开托管评审时，Source Control 会在分支上下文行中保持当前分支可见，因此 Create PR 操作不会替换分支标签。
关联的评审会连同状态一起显示在侧边栏，方便你判断分支是仍处于打开状态、已合并还是已关闭。
当 Orca 拿到关联 PR / MR 的 URL 时，分支上下文行会显示一个紧凑的 Open review page in browser 链接——一键即可跳转到 GitHub、GitLab、Bitbucket、Azure DevOps 或 Gitea 上的评审页面，无需打开内部 PR 视图。
从关联评审或 issue 的溢出菜单中选择 Open in Orca browser，即可在当前 worktree 的浏览器标签页中打开其 URL，不必离开终端或任务视图。
对于 GitHub pull request，可通过侧边栏的 PR 操作菜单复制评审链接、关闭评审，或在确认状态变更后重新打开。
对于 GitHub 草稿 pull request 和 GitLab merge request，可使用侧边栏操作进行 Mark ready for review 或 Close。GitLab 的操作会移除其 Draft/WIP 状态；评审仍处于草稿状态时，合并与自动合并均不可用。
对于关联的 GitLab merge request，可在 Checks 侧边栏打开评审链接菜单，执行 Unlink MR 或 Link another MR。
在 SSH 工作区中，GitLab merge request 和 issue 操作会通过工作区主机的 GITLAB_HOST 路由，确保写入到达正确的服务器。
GitHub 的检查、评审和评论会在 PR 标签页中内联打开；GitLab 的 merge request 和 issue 也在同一个评审界面中打开。
对于 GitLab 流水线，Checks 侧边栏包含 bridge 和子流水线任务（不仅是顶层任务）。展开某个任务会在可用时加载该任务的 trace（日志）——与 GitHub 检查详情的打开位置相同——因此失败的任务不会是“无内联详情”的死胡同。
在 Checks 面板中，你可以回复评审线程中的任意评论，而不仅是根评论。
GitHub PR 会话评论和内联评审线程评论带有反应选择器，与 GitHub 的八种反应一致（👍 👎 😄 😕 ❤️ 🎉 🚀 👀）。已有的反应标签可切换。GitLab 评论保持不变。
分组显示的 PR 评论区块按最新优先排序，新回复会将其线程顶到最上方。Timeline 标签页仍按最早优先排序。
当 GitHub pull request 存在失败的检查时，可在 PR 视图中使用 Fix broken checks，将失败的检查名称和链接交给 agent 处理。
### 自动合并 对于打开状态的 GitHub PR，PR 视图的合并按钮提供 Enable auto-merge 选项，让 GitHub 在满足条件（检查通过、必需评审完成）后自动合并分支。合并方式遵循仓库默认设置，为 Squash and merge、Create merge commit 或 Rebase and merge 之一——仓库不允许的方式不会显示。通过同一控件可使用 Disable auto-merge 取消待执行的自动合并。当基础分支启用了 GitHub 的 merge queue 时，同一控件会显示为 Merge when ready，将 PR 加入队列。对于 GitHub 标记为草稿、已关闭、存在冲突或不稳定的 PR，以及不允许自动合并的仓库，自动合并控件会隐藏——这些情况下只能看到手动合并操作。 ### 堆叠式 pull request 当你创建 GitHub pull request 时，如果所选基础分支已有打开的 PR，创建器会提供 Stack this PR above #N 选项。勾选后会创建一个 GitHub Stack（或加入父 PR 已有的 stack），提交按钮标签变为 Create PR in stack（或 Create draft PR in stack / Push & Create PR in stack）。同时会显示一个小预览，展示父 PR 和新分支。该选项仅限 GitHub，且只在执行主机支持堆叠创建时出现。GitLab merge request 和 Bitbucket pull request 仍为单一 PR 创建。 当 GitHub 将某个 pull request 登记为 stack 的一部分时，PR 侧边栏会显示可折叠的 Stack #N 映射：你在 stack 中的位置、stack 大小以及 stack 的基础分支。展开后可查看各层的顺序及其状态（打开、草稿、检查待定/失败、需要评审、冲突、已合并、已关闭）。点击某一层即可在 Orca 中打开对应的 PR。 堆叠感知合并会将单一 PR 的合并标签替换为 Merge through #N · M PRs（若仓库使用 merge queue 则为 Queue through #N · M PRs）。该操作覆盖当前 PR 及 stack 中其下方的所有 PR。当 stack 元数据完整时，确认对话框会列出包含的编号。原子化 stack 合并采取“全有或全无”策略——任何一层无法合并，则全部不合并。未在 GitHub 登记过 stack 元数据的普通依赖 PR 链，仍保持正常的单一 PR 合并流程。GitLab merge request 不受影响。 ## Issuesissue 抽屉让你在 Orca 内浏览、筛选和编辑 GitHub 与 GitLab 的 issues。从 GitHub issue 或 PR 创建 worktree 时会打开交互式工作区创建器（而非静默的后台创建），因此 issue 命令自动化、SSH 目标和文件夹工作区与其他创建路径的行为一致。创建器会预填任务名并关联 issue，使评审与任务保持绑定。
对于 GitHub issues，详情对话框包含一个 Activity 区块，将评论与时间线事件交错展示——分配、提及、交叉引用、状态变更和项目列移动——让你无需离开 Orca 就能看到完整历史。
使用工作区侧边栏中的关联 issue 菜单，无需打开抽屉即可复制 issue 链接。
对于 GitLab 仓库，抽屉会列出所选项目的打开 issues，并可缩小范围只显示分配给你的 issues。
## Actions GitHub Actions 检查失败时，worktree 上会显示红色标记。点击即可内联查看失败任务的日志。 ## Tasks Orca 在 Tasks 侧边栏条目下提供完整的 GitHub Projects 视图——跨仓库浏览项目卡片、按源仓库筛选、查看草稿 pull request 状态，并可从任意卡片创建 worktree。看板类项目视图渲染为可拖拽的 kanban，拖放操作会将卡片的状态字段写回项目；表格及其他项目视图保持列表布局。 ## 故障排查 如果 PR 状态、检查或 Tasks 无法刷新——可能是速率限制、gh auth、权限或网络问题——请参阅 Troubleshooting GitHub errors。 ## 下一步 从 Orca 提交并推送——暂存更改、推送分支，然后创建托管评审。 Linear items drawer——当任务源不在你的 git 平台内时使用 Linear。 Troubleshooting GitHub errors——速率限制、认证及 gh 故障。