托管审查、Issue 与 Actions

托管代码评审是 worktree 的一等公民。DevAgent 会把 worktree 关联到它们的 pull request 或 merge request，在行内展示评审状态，并让你无需离开应用就能分诊 issue。

连接一个 provider

从 设置 → 集成 连接你的仓库所使用的 provider。GitHub 对 Actions 和 issue 的支持最深入；GitLab 的 merge request 和 issue 使用相同的 worktree 评审流程。

Bitbucket Cloud 从同一个面板在应用内连接——用 Email & API token 或 Access token 点击 Connect。DevAgent 会在保存前验证凭据，并且可以从 Source Control 创建 pull request。Bitbucket Cloud 没有 draft PR，因此撰写器会隐藏 Draft 开关。ORCA_BITBUCKET_* 环境变量仍然优先于已保存的凭据。Azure DevOps 和 Gitea 的 pull request 会与 GitHub、GitLab、Bitbucket 一起出现在 worktree 侧边栏和 Checks 面板中——worktree 创建流程会在推送前检查它们是否有远程冲突。

评审

• 一旦 worktree 被推送，就可以从 Source Control 面板打开托管评审——在创建之前确认 base 分支、标题、描述和 draft 状态。
• 在你创建或打开托管评审时，Source Control 会在分支上下文行中保持当前分支可见，因此 Create PR 操作永远不会替换掉分支标签。
• 已关联的评审会带着状态出现在侧边栏里，让你能分辨该分支是仍然打开、已合并还是已关闭。
• 当 DevAgent 拥有已关联 PR / MR 的 URL 时，分支上下文行会显示一个紧凑的 Open review page in browser 链接——一键即可跳转到 GitHub、GitLab、Bitbucket、Azure DevOps 或 Gitea 上的评审，而无需打开内部的 PR 视图。
• 对于 GitHub pull request，可使用侧边栏中的 PR 操作菜单来复制评审链接、关闭评审，或在确认状态变更后重新打开它。
• GitHub 的 check、review 和评论会在一个 PR 标签页 中行内打开；GitLab 的 merge request 和 issue 在同一个评审界面中打开。
• 对于 GitLab 流水线，Checks 侧边面板会包含 bridge 和 child 流水线的 job（而不仅是顶层 job）。展开某个 job 会在可用时加载该 job 的 trace（日志）——与 GitHub check 详情打开的位置相同——因此失败的 job 不会沦为一个“无行内详情”的死胡同占位符。
• 在 Checks 面板中，你可以回复评审线程中的任意评论，而不仅是根评论。
• GitHub 的 PR 会话评论和行内评审线程评论都有一个表情反应选择器，与 GitHub 的八种反应一致（👍 👎 😄 😕 ❤️ 🎉 🚀 👀）。已有的表情标签是可切换的。GitLab 评论保持不变。
• 分组后的 PR 评论区块按最新在前排序，这样一条新回复会把它所在的线程顶到最上面。Timeline 标签页 则保持最旧在前。
• 当某个 GitHub pull request 有失败的 check 时，可以从 PR 视图使用 Fix broken checks，把失败的 check 名称和链接交给 agent。

自动合并

对于打开的 GitHub PR，PR 视图的合并按钮会提供 Enable auto-merge，让 GitHub 在其各项要求（check、必需的评审）通过后自动合并该分支。合并方式遵循仓库的默认设置，是 Squash and merge、Create merge commit 或 Rebase and merge 之一——仓库不允许的方式不会显示。可以从同一个控件使用 Disable auto-merge 来取消一个待生效的自动合并。当 base 分支使用 GitHub 的 merge queue 时，同一个控件会显示为 Merge when ready，并将该 PR 加入队列。对于 GitHub 报告为 draft、closed、conflicting 或 unstable 的 PR，以及不允许自动合并的仓库，自动合并控件会被隐藏——在这些情况下你只会看到手动合并操作。

堆叠式 pull request

当你创建的 GitHub pull request，其所选的 base 上已经有一个打开的 PR 时，撰写器会提供 Stack this PR above #N。勾选它会创建一个 GitHub Stack（或扩展父级已有的 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 的 base 分支。展开它可以看到按顺序排列的各层及其状态（open、draft、check pending/failed、需要评审、conflicts、merged、closed）。点击某一层即可在 DevAgent 中打开那个 PR。

stack 感知的合并会把单 PR 的合并标签替换为 Merge through #N · M PRs（当仓库使用 merge queue 时则为 Queue through #N · M PRs）。该操作会覆盖当前 PR 以及 stack 中它下面的每一个 PR。当 stack 元数据完整时，确认框会列出所包含的编号。原子式 stack 合并采取失败即中止（fail closed）策略——如果任何一层无法合并，则全部都不合并。没有 GitHub 登记 stack 元数据的普通依赖式 PR 链，仍保持常规的单 PR 合并流程。GitLab 的 merge request 不受影响。

Issue

issue 抽屉让你可以在 DevAgent 内部浏览、筛选和编辑 GitHub 与 GitLab 的 issue。从一个 GitHub issue 或 PR 创建 worktree 会打开交互式的 workspace 撰写器（而不是无声的后台创建），这样 issue-command 自动化、SSH 目标和文件夹 workspace 就与其他创建路径一样工作。撰写器会预填任务名并关联该 issue，从而让评审始终附着在任务上。

对于 GitHub issue，详情对话框有一个 Activity 区块，把评论与时间线事件穿插在一起——分派、提及、交叉引用、状态变更以及项目列移动——这样你无需离开 DevAgent 就能看到完整的历史。

使用 workspace 侧边栏中的“已关联 issue”菜单，无需打开抽屉即可复制一个 issue 链接。

对于 GitLab 仓库，抽屉会列出所选项目中打开的 issue，并可以把列表收窄到分派给你的 issue。

Actions

失败的 GitHub Actions check 会作为一个红色小标签出现在 worktree 上。点击进去可以行内查看失败 job 的日志。

任务（Tasks）

DevAgent 在 Tasks 侧边栏条目下提供了一个完整的 GitHub Projects 视图——跨多个仓库浏览项目卡片、按来源仓库筛选、查看 draft pull request 状态，并从任意卡片创建 worktree。

疑难解答

如果 PR 状态、check 或 Tasks 无法刷新——限流、gh 认证、权限或网络问题——请参阅 GitHub 错误疑难解答。

下一步

• 在 DevAgent 中提交并推送——暂存改动、推送分支，然后创建托管评审。
• Linear 条目抽屉——当任务来源在你的 git provider 之外时使用 Linear。
• GitHub 错误疑难解答——限流、认证以及 gh 失败问题。