源代码管理

T3 Code 与 GitHub、GitLab、Forgejo、Gitea、Bitbucket、Azure DevOps、GitCafe 以及 Cursor Origin 集成，用于克隆和发布仓库、创建拉取请求（pull request），以及审查变更。

审查回合变更

回合（turn）的变更文件和差异只显示该回合自己的工作。回合在拉取、合并或变基时，Git 带进来的文件不会列入。如果该回合编辑过某个文件、提交过它，或在其中解决过冲突，这个文件会留在列表里。请用分支比较来审查相对于基准分支的全部变更。恢复仍会返回完整保存的工作区。

在 Web 端和桌面端，打开差异窗格的来源选择器，选择 提交，即可一次审查一个本地提交。列表显示分支比较中最新的 100 个提交。合并提交显示的是相对于其第一父提交的变更。

当对话线程（thread）的仓库在任意分支上本地已有该提交时，来自受支持代码托管方的提交链接会在差异窗格中打开。否则，拉取请求（pull request）中的提交链接会打开该拉取请求。其他提交链接遵循你的 在何处打开链接 设置；在 Web 端，若该设置会打开新标签页，T3 Code 会先显示 打开链接 按钮。Command/Ctrl+单击始终在浏览器中打开链接。提交链接还遵循 设置 → 差异 中的 在 T3 Code 中打开拉取请求 设置。

连接账户

在运行 T3 Code 服务器的机器上安装 Git，并配置身份验证。若是远程环境（environment），请在远程机器上完成这些步骤。登录之后，打开 设置 → 源代码管理，选择 重新扫描。

GitHub

T3 Code 直接与 GitHub 的 API 通信，只需要一个令牌。以下方式都可以使用，优先顺序如下：

1. 保存在 设置 → 源代码管理 → GitHub 中的令牌。它存放在服务器的密钥存储里，不需要 GitHub CLI 也能使用。
2. 服务器环境中的 GH_TOKEN（GitHub Enterprise Server 使用 GH_ENTERPRISE_TOKEN，并配合 GH_HOST）。
3. GitHub CLI 2.81.0 或更高版本，并已用 gh auth login 登录。

如果 gh 登录了多个账户或主机，请在同一处展开 GitHub，为每个主机选择所用账户，或关闭某个主机。已保存的令牌或 GH_TOKEN 优先于这一选择；主机一旦关闭，无论哪种情况都会保持关闭。

对于 GitHub Enterprise，请使用 gh auth login --hostname YOUR_HOST 登录。一旦某台主机已有凭据，T3 Code 就会把自定义服务器名称当作 GitHub。

Forgejo 与 Gitea

在 T3 Code 服务器上安装 Forgejo CLI（fj） 或 Gitea CLI（tea） 0.16 或更高版本。 使用 fj --host https://your-server auth add-token 或 tea login add 登录。你使用的每一台服务器都要重复此操作，包括 Codeberg。

T3 Code 优先采用匹配的 fj 登录；当 fj 不可用，或没有该服务器的登录时，回退到 tea。一旦选定账户，即使操作失败，也仍使用该账户。设置中会显示检测到的 CLI。Forgejo 与 Gitea 共用一个集成条目。托管在 URL 子路径下的服务器（例如 https://example.com/forgejo）使用 tea，因为 fj 0.6 在检查自己的账户时不会保留子路径。

克隆或发布时，请使用完整的仓库 URL 来选定具体的服务器。只配置了一台 fj 服务器时，可以使用 owner/repo；在 fj 不可用或未配置时，也可以配合你的默认 tea 登录使用。有多台 fj 服务器时，请使用完整 URL。如果同一台服务器上有多个 tea 账户，请用 tea login default <login-name> 选定其中一个。对该服务器执行 Git 推送和克隆时，还需要 Git 凭据或 SSH 密钥。

GitLab

安装 GitLab CLI，然后登录：

glab auth login

Bitbucket

打开 设置 → 源代码管理，展开 Bitbucket，并填入以下其中一项：

• 访问令牌：为单个仓库、项目或工作区创建的令牌。它只能访问创建时所针对的范围。
• Atlassian 账户邮箱 与 API 令牌：你账户的 Atlassian API 令牌。它可以访问你能够访问的每一个仓库。请为其授予仓库和拉取请求（pull request）的读写权限，以及用户读取权限（read:user:bitbucket）。

离开字段即会保存，并立即生效。两项都已保存时，以访问令牌为准。凭据保存在该环境的服务器上，因此要配置远程环境，请先选中它。已保存的令牌无法再次查看；输入新的令牌即可替换，或选择 移除，清除为 Bitbucket 保存的全部内容。

如果没有保存凭据，T3 Code 会回退到服务器环境中的这些变量。修改之后请重启服务器：

export T3CODE_BITBUCKET_ACCESS_TOKEN="your-access-token"
# or
export T3CODE_BITBUCKET_EMAIL="you@example.com"
export T3CODE_BITBUCKET_API_TOKEN="your-token"

对于后台服务（background service），将这些 KEY=VALUE 条目写入 T3 主目录下的 service.env， 然后运行 t3 service restart。服务的安装和更新会保留该文件。

Azure DevOps

安装 Azure CLI，添加 DevOps 扩展并登录：

az extension add --name azure-devops
az login

GitCafe

安装 GitCafe CLI 并登录：

bun install -g @gitcafe/cli
cafe auth login --host https://git.cafe/api

也可以打开 设置 → 源代码管理，展开 GitCafe，并输入令牌。该令牌保存在服务器的密钥存储中，立即生效，并且会在 CAFE_TOKEN 和 cafe 登录之前被使用。也可以在服务器的环境中设置 CAFE_TOKEN，然后重启服务器。两种令牌都只会发送到 git.cafe；如果你设置了 CAFE_HOST，CAFE_TOKEN 会遵循它。staging.git.cafe 上的仓库需要使用 --host https://staging.git.cafe/api 单独登录。

GitCafe 的拉取请求目前还不支持行评论。合并一个栈时，会通过 GitCafe 将其合入；更新一个分支，会重新堆叠它上方的各层。

Cursor Origin

安装 Origin CLI 并登录。登录还会为 origin.cursor.com 配好 Git 凭据：

curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
origin auth login

若克隆或推送时要求输入用户名，请运行 origin auth setup-git，让 Git 重新指向该 CLI 的凭据。Origin 仓库使用 HTTPS，并以私有方式发布。从 GitHub 镜像而来的仓库，其拉取请求仍留在 GitHub 上；请从 GitHub 远程打开它们。

开始、克隆或发布项目

要从零开始，在命令面板（Cmd/Ctrl+K）中选择 新建项目，或在任意客户端（client）的 添加项目 下选择 新建项目，然后输入名称。T3 Code 会在 ~/.t3/projects（你的 T3 数据目录中的 projects 文件夹）里创建一个 Git 仓库，其中包含 README、图标和首次提交，然后在其中打开一条新的对话线程（thread）。在该项目（project）拥有对话线程之前，新的对话线程都在它的文件夹里工作，即便你的默认选项是新建工作树（worktree）。文件夹按项目命名，例如 “Pinball Stats” 对应 pinball-stats。打开 在 GitHub 上创建私有仓库，即可同时发布。如果这台机器上的 Git 没有配置姓名或邮箱，创建项目时不会包含首次提交。

在命令面板中使用 添加项目（Cmd/Ctrl+K）来克隆仓库。选择一个托管提供方（provider），或粘贴一个 Git URL，然后选择保存位置。从 GitHub、GitLab、GitCafe、Codeberg 或 Bitbucket 复制的分支页面或文件页面也同样可用：T3 Code 会克隆该仓库的默认分支。对于其他托管方，请粘贴仓库的克隆 URL。项目会立即打开，克隆在后台进行：你可以写下第一条提示词，发送则会等到文件就位。一条提示条会显示进度，并允许取消；如果克隆失败，可以从该提示条或 Composer（编写器）上方的横幅重试。当托管方拒绝这台机器的 SSH 密钥时，T3 Code 会改用该主机的 Git 凭据，通过 HTTPS 克隆，项目的远程也会使用 HTTPS URL。

要按 ghq 的方式排布克隆，请在 设置 → 对话线程 中打开 克隆到托管方文件夹（移动端则在 源代码管理 中）。此后，克隆默认放在 添加项目的起始位置 下的 <host>/<owner>/<repo>，因此把该项设为 ~/ghq，即可与 ghq 共用文件夹。克隆之前，你仍然可以更改目标位置。

对于没有远程的本地 Git 仓库，发布仓库 会创建一个托管仓库，将其添加为 origin，并推送你的提交。如果还没有任何提交，它会创建远程；请在推送之前完成首次提交。

创建拉取请求

使用对话线程（thread）的 Git 操作来提交、推送并创建拉取请求（pull request）。T3 Code 可以根据你的变更生成提交说明、审查标题和描述。描述还会参考对话线程中的工作，包括它运行过的检查。

即使推送时没有设置上游，已有的分叉 PR 也可以出现在分支旁边。如果因为多个远程都持有该分支而导致徽章缺失，请用 git branch --set-upstream-to=<remote>/<branch> 将该分支的上游设为你要使用的远程。

在 设置 → 源代码管理 → 提交与拉取请求 中，选择提交说明以及拉取请求标题和描述的撰写方式。仓库约定 使用项目（project）的说明以及最近的提交主题。自定义说明 会把你自己的说明用于提交和拉取请求。

审查与合并

打开 拉取请求（pull request），即可审查变更和评论、请求审查者、检出分支或进行合并。在托管方允许的地方，你可以编辑审查的标题和描述，以及你自己的评论。在可以编辑描述的地方，还可以从摘要标签页勾选其中的复选框（移动端为概览标签页）。GitLab 把这些称为合并请求。

指向拉取请求某一部分的链接会打开那一部分：评论或审查会在动态中标出，变更行链接会在对应行打开文件，检查链接会打开检查，提交链接会打开该提交的变更。在 Web 端和桌面端，将指针悬停在评论链接或提交链接上可以预览。

在移动端，拉取请求 会列出你已连接的各个环境（environment）中的审查。打开一条审查，即可阅读它的描述、动态、提交和变更文件。行评论在你提交审查之前一直是草稿。处理 PR 会打开一个已附上该审查的聊天；发送第一条消息时，会根据该审查的分支准备一个工作树（worktree）。

先前加载过的列表、审查详情、指南和差异页面，在移动端没有连接时仍可阅读，包括重启应用之后。环境重新连接后，已保存的内容会刷新；提交变更则需要连接。

在设置 → 源代码管理中启用 合并时移除智能体署名，即可从 GitHub 的合并提交和压缩提交说明中，移除已识别的智能体共同作者行和 generated-by 行。人类共同作者的署名会保留。该设置默认关闭，项目（project）可以覆盖它。它也适用于自动合并，但不适用于合并队列或原生的栈合并。原始提交会保留自己的说明，因此合并和变基仍可能在这些提交中保留智能体署名。

在 Web 端和桌面端，于 GitHub 拉取请求列表中按住 Shift，即可使用快捷操作。要关闭多条，请按 关闭，在同一组内拖过各行，然后松开。松开之前按 Escape 即可取消。关闭失败的条目会留在列表中，以便重试。

GitHub、GitLab 和 Azure DevOps 支持在检查尚未完成时自动合并。GitHub 还支持批准等待中的分叉工作流，以及为已合并的变更打开还原拉取请求。

拉取请求共享默认关闭。在设置 → 环境 → 拉取请求共享中（移动端为环境下的拉取请求路由），对每一个你信任其可以共享源代码管理访问权限的环境，选择 读取 PR 或 读取并操作。请在此客户端（client）上同时启用原来的环境，以及应答其请求的环境。读取并操作 可以使用比原环境凭据更宽的权限；请只对你所控制并信任的环境启用它。更改已保存的端点，或移除某个环境，会清除它的权限。

此后，审查详情、已关联的 PR 状态，以及允许的审查操作，可以使用另一台已连接的环境，只要它在同一主机上以同一账户登录。每一台都需要在该主机上有一个项目。执行操作时优先使用已连接的本地环境，它也可以应答缓慢或失败的读取。浏览器和移动客户端需要一个已配对的环境，才能使用它的 GitHub 凭据。凭据留在各自的机器上。GitHub 故障期间，先前已验证的凭据在十分钟内仍可用于路由；新凭据必须先完成验证。结果不确定的操作绝不会自动改到别处重试。列表、差异，以及 Git 操作中的检出或 PR 创建，仍使用项目的环境。

对于 Azure DevOps，请到托管方网站上修改评论。Bitbucket 不支持重新打开已拒绝的拉取请求。

审查指南

审查指南目前处于测试阶段。在设置 → 源代码管理中打开 审查指南，即可为该服务器上的拉取请求加上 指南 标签页。在移动端，用 下一步 和返回按钮在各个停留点之间移动；过时的指南会提供重写，并隐藏已不再与当前变更相符的摘录。

指南 标签页让你不必逐行阅读，就能导览一次拉取请求：各个停留点按阅读顺序经过这次变更。每个停留点指向值得阅读的那些行；标为 仔细查看 的停留点，则有一项只有维护者才能做出的判断。重命名和快照这类机械性变更会集中到末尾，每个有变更的文件都会出现在导览中的某处。审查中已经解决的讨论不会列入。对于栈中的拉取请求，指南只覆盖该层，并可能指出更下层引入了什么，或更上层用到了什么。

选择 撰写指南，让设置 → 源代码管理中的审查指南模型在一次临时检出里阅读这次变更；如果没有设置该模型，则使用源代码管理的写作模型。检出中的内容不会被改动，大型拉取请求需要几分钟；你可以转到应用里的其他地方。在 Web 端，指南就绪时会通知你；在移动端，回到指南即可查看进度。Claude 和 Codex 可以撰写指南。指南会保留给所有使用此服务器的人。要重新撰写，例如在推送之后，或更改了模型或说明之后，请从该拉取请求的 ⋯ 菜单中选择 重新撰写指南。

在 Web 端阅读某个停留点时，在摘录里选中若干行，即可把评论加入你的审查，或就此询问智能体；这些评论会和 代码 标签页里的评论一起等待，直到你发送审查。选择一条建议的问题，或选择 询问此停留点，即可打开一条已经知道你正在看哪个停留点的对话线程（thread）。在最后一个停留点上，完成审查 会打开审查，并带上你收集的全部内容。

智能体也可以撰写指南：请它为一组拉取请求准备指南，它就会替你启动。每一份都经由检出中包含该仓库的那个项目来阅读。

要让指南符合你的习惯，请在设置 → 源代码管理中编写 审查指南说明，例如先展示什么、跳过什么；项目可以覆盖这些说明。它们改变的是侧重点和顺序，而不是指南的布局，也不是它覆盖哪些文件。

将文件标记为已查看

在 代码 标签页里，读完一个文件后把它勾掉，文件就会折叠；工具栏会一直显示当前计数。勾选属于拉取请求，而不属于某一次提交，因此把标签页限定到单次提交时，这些勾选仍然保留。你清除标记之后又被推送改动的文件，会重新标为 已变更。

在 GitHub 上，这些就是 GitHub 自己的已查看标记，因此一条审查可以在 T3 Code 与 github.com 之间双向同步。Forgejo、GitLab、Bitbucket、Azure DevOps 和 Cursor Origin 没有 T3 Code 能够读取的记录，因此改由你所连接的服务器保存：它们会跟随你出现在连接到该服务器的各个应用里，但托管方自己的网站不会显示，计数会显示为 已在 T3 Code 中查看。

在移动端，打开一个变更文件，并从它的标题栏将其标为已查看。已查看的文件会折叠，其标记遵循与 Web 端和桌面端相同的规则。

故障排除

• 未认证： 在服务器上运行提供方（provider）的登录命令（command），然后重新扫描。对于 Bitbucket，请检查设置 → 源代码管理中保存的凭据，或确认正在运行的服务器已经收到这些环境变量。
• 无法验证 GitHub 登录： 将 GitHub CLI 更新到至少 2.81.0，或在设置 → 源代码管理中保存一个令牌。
• 账户已连接但推送失败： 请检查 Git 远程的凭据。SSH 与 HTTPS 远程可能需要单独配置，这与托管提供方的 API 访问是分开的。
• 审查无法加载： 在解决连接、权限或速率限制的同时，到托管方网站上打开它。

已关联的拉取请求

一条对话线程（thread）可以包含多个拉取请求（pull request），包括同一主机上另一个仓库中的审查。在命令面板或 已关联的拉取请求 面板中使用 关联拉取请求，或在对话里右键单击拉取请求链接。从 Git 操作创建拉取请求会自动关联；智能体用 gh pr create 或 glab mr create 创建时也会自动关联。智能体可以用 link_pull_request 工具关联其他拉取请求。

在命令面板中使用 将拉取请求关联到对话线程，让该拉取请求与对话线程保持在一起。在拉取请求页面的某条审查中，关联到对话线程 可以让你搜索一条活跃的对话线程。审查的标题栏还会列出关联到它的对话线程，包括已归档的对话线程，以便你回到它们的上下文。

对话线程徽章会显示栈的层数，或者当前审查编号外加其余链接的数量。点击包含不止一条审查的徽章，会打开 已关联的拉取请求 面板。在移动端，Git 概览会列出已关联的审查及其栈；点按一条审查即可打开。关联和取消关联可在 Web 客户端（client）与桌面客户端中使用。

已关联的拉取请求 面板会列出每一条审查，并把各个栈分组。从它的行菜单中取消关联某条审查。已取消关联的栈层不会进入之后的同步。处于打开状态的已关联审查会在服务器上刷新；已关闭的审查会定期刷新，以便发现在托管方上被重新打开的情况。已合并的审查在被请求时刷新。已收束的对话线程，其审查会停止刷新，直到你取消收束。启用 自动收束已合并的对话线程 后，当每一条已关联审查都进入终态时，对话线程可以收束。一条打开的或尚未同步的链接会让它保持活跃。

让智能体关注、监视或照看某个拉取请求，它就会调用 watch_pull_request。对话线程处于活跃状态时，服务器每两分钟检查一次该拉取请求，并在下列情况唤醒智能体：某项检查失败或正在等待维护者批准、必需的检查已经通过、其他人发表了评论或审查，或者分支开始发生冲突。同一项目（project）中关注同一拉取请求的对话线程共用一次检查。在 GitHub 上，一次检查会先询问是否有变化，只有确实有变化时才读取该拉取请求，从而使关注停留在 GitHub 的速率限制之内。来自你自己账户的评论不会唤醒它。关注会在拉取请求合并或关闭后结束，也会在连续 10 次唤醒都只带来评论之后结束，在连续 8 次读取失败之后结束，或在你于该对话线程上按下停止时结束。速率限制只会暂停关注。收束或归档对话线程也会结束它的全部关注。开始新的关注之前，请先取消收束该对话线程。再次关注某个拉取请求时，不会重复上一次关注已经报告过的检查或冲突消息；取消关联该拉取请求会清除这些记录。子智能体不能关注拉取请求；把工作委派给它们的那条对话线程可以。要自己开始或停止，请使用 已关联的拉取请求 面板中的行菜单。在对话线程详情卡片中，被关注的拉取请求会显示一只眼睛；点击它即可停止关注。

被关注的对话线程在两次唤醒之间仍算作正在工作，因此会留在 进行中 分区，并且不会自动收束。智能体把工作交还给你时会停止关注，对话线程随后回到你的收件箱。

跨仓库链接使用同一主机上的项目。Azure DevOps 的审查需要一个从对应组织和仓库检出的项目。

GitHub 栈

拉取请求（pull request）页面会显示每个 PR 在其 GitHub 栈中的位置。在审查中打开栈徽章，即可在它的各层之间切换。合并栈 会把所选拉取请求，以及它下方每一个尚未合并的层，一起提交给 GitHub，并遵守分支规则和合并队列。确认时会显示范围和合并策略。合并之后，GitHub 会对其余的栈进行变基。

变基栈 自下而上更新远程分支，且不改动你的本地检出。它可能会改写历史，并重新开始检查。如果某一层失败，更早的更新会保留；请先解决该层，然后再重试。下层被修订之后，即使这些变更看起来彼此独立，GitHub 仍可能要求手动解决冲突。栈操作需要一个支持这些操作的环境（environment）。