版本控制

设置 → 版本控制 做两件事：为 Codeg 指定它应当运行的 Git 可执行文件，以及保存那些账户 —— GitHub、GitLab，以及任何其他 Git 服务器 —— 它们的凭据让克隆、拉取和推送无需密码提示即可完成。应用把它描述为：“配置 Git 可执行文件并管理 GitHub 账户。”

从 0.27 起，这些账户还多了一份工作：仓库面板通过它们读取你的 issue 和 pull request，并以触发该任务的那个账户推送交付的分支。这里有一个 GitHub 或 GitLab 账户，那个面板才能用起来。

你在这里添加的每个账户都本地存储在你的机器上；令牌或密码存入你操作系统的系统密钥环，绝不进入应用的数据库或网络。当 Codeg 代表你运行一条 git 命令时，它会按服务器查找匹配的账户，并为你提供凭据 —— 具体机制见下方的凭据的使用方式。

Git 可执行文件

第一个面板显示 Codeg 是否找到了可用的 git：

• 已检测到 Git （绿色），附带版本字符串和解析出的 路径 —— Codeg 将使用的自动检测到的可执行文件。
• 在本系统上未找到 Git （红色） —— 在你的 PATH 上没有找到任何可用的。

自定义 Git 路径 让你可以覆盖自动检测 —— 点击它，输入一个绝对路径（占位符是 /usr/bin/git），然后 保存。Codeg 会在保存前测试该路径：如果它不是一个有效的 git 可执行文件，保存会被拒绝并报错，这样你就不会不小心把它指向某个无法运行的东西。把该字段留空即可回退到自动检测的路径。

只有在少见的情况下你才需要这个 —— 当正确的 git 并非你 PATH 上排在最前的那个时：某个版本管理器的 shim、一个便携安装，或者你更希望 Codeg 使用的第二份副本。

GitHub 账户

用于 GitHub 的凭据 —— github.com 或某个 GitHub Enterprise 服务器。每个账户由一个 服务器 URL（默认为 https://github.com）加上一个 个人访问令牌（Personal Access Token） 组成。添加账户 会打开一个带有两项便利功能的对话框：

• 生成令牌 会直接在你的浏览器中打开服务器的新建令牌页面（…/settings/tokens/new），并预填名称 codeg 以及 Codeg 需要的权限范围 —— repo、read:org、workflow、gist、read:user、user:email。在那里创建它，然后复制回来。
• 验证并添加 不只是存储令牌 —— 它会先调用 GitHub API 来验证它，成功后填入你的用户名、头像和令牌的实际权限范围。无效或过期的令牌会当场被拒绝，根本不会被保存。

每个已保存的账户都会显示它的用户名、服务器和被授予的权限范围，并带有四个操作：

• 测试 会对服务器重新验证已存储的令牌，以便你确认令牌仍然有效（或发现它已被吊销）。
• 更新令牌 会在保留账户本身的前提下替换存储的密钥，验证方式与「验证并添加」相同。令牌过期或轮换时用它。它比看上去要紧：仓库任务是钉在触发它们的那个账户上的，删掉再添加回来，对那些任务而言就是另一个账户，而更新令牌能让它们继续正常工作。
• 设为默认 将它标记为首选账户 —— 见默认规则。
• 垃圾桶 按钮会在确认后移除它，并从系统密钥环中删除它的令牌。

如果某个账户的头像取不到，它会回退成显示姓名首字母，而不是一个空圆圈。

GitLab 账户

0.27 新增，与 GitHub 面板一一对应：一个账户由一个 服务器 URL（https://gitlab.com，或你自己的实例）加上一个 个人访问令牌 组成，存储之前会先对 GitLab API 做验证，成功后填入用户名和头像。

令牌需要 api 权限范围。请在 GitLab → 偏好设置 → 访问令牌 下创建；面板里也内联写着这一点。其余一切都和 GitHub 面板完全一样：测试、更新令牌、设为默认和移除。

仓库面板正是通过这个面板读取一个 GitLab 项目的 issue 与 merge request，并以这个身份推送交付的分支。

Git 账户

同样的思路，适用于上面两个面板覆盖不到的一切 —— Bitbucket、Gitea、普通的自托管服务器。面板自己的说明是：“管理非 GitHub Git 服务器（GitLab、Bitbucket、自托管等）的凭据。”

添加对话框要求填写三个字段 —— 服务器 URL（例如 https://git.example.com）、用户名（或电子邮件）和 密码 / 令牌。与 GitHub 和 GitLab 面板不同，这里没有可供验证的 API，因此凭据按原样存储；这里的 测试 只是确认系统密钥环中存在某个凭据，而不是对着服务器去检验它。其他一切 —— 设为默认、移除 —— 工作方式相同。

该用哪个面板，以及为什么现在这件事有了分别

这三个面板其实是同一份存储，只是在显示上分了组。对于纯粹的 git 流量 —— 克隆、拉取、推送 —— 这种划分毫无影响：匹配是按主机名做的，所以放在哪个面板里的凭据都能服务它的主机。GitHub 和 GitLab 面板多出来的是一个已声明的提供商，而这正是告诉 Codeg 对这台主机该说哪一种 API 的东西。

一个账户落在哪个面板，取决于你是从哪个对话框添加它的，而不是它的 URL —— 这也是唯一能把自托管的 GitLab 和 GitHub Enterprise 分辨开来的办法。一个什么都没声明的账户仍然对两家 forge 都适用，而 Codeg 会从主机名去猜：gitlab.com，或任何把 gitlab 作为一个完整标签的主机，读作 GitLab；其余一律读作 GitHub。

所以，这个声明真正派上用场的是那些含糊的主机。一台域名里不带 gitlab 的自托管 GitLab，否则就会被当成 GitHub 去对话，仓库面板对它就会失败——而一个位于 gitlab.com 或 gitlab.example.com 上的通用账户则完全可用。从正确的对话框添加，就把这次猜测彻底去掉了。

在提供商字段出现之前存下的账户，仍沿用它们当初归档的规则：github.com 归入 GitHub 账户，其余归入普通 git 凭据。

凭据的使用方式

你很少直接调用这些账户 —— 它们是通过 git 本身来工作的。Codeg 注册为 git 的凭据助手（credential helper），并通过 GIT_ASKPASS 提供凭据，因此当它运行的某个 git 操作需要某台主机的登录信息时，Codeg 会代为应答，而不是让 git 停下来提示你。

匹配是按主机名进行的。对于 github.com 上的远程仓库，Codeg 会查找服务器为 github.com 的账户；对于 gitlab.example.com，则查找服务器为 gitlab.example.com 的账户。匹配器的工作方式带来两点结论：

• 它绝不会使用不相关的账户。 如果没有账户匹配远程仓库的主机，Codeg 什么都不提供，让 git 回退到它自己的配置 —— 一台服务器的令牌绝不会被提供给另一台。
• 默认账户只在同一主机内打破平局。 当多个账户共享同一个服务器时（比如两个 github.com 登录），被标记为 默认 的那个才是被使用的。跨不同主机时，每个远程仓库都使用它自己匹配的账户，无论哪个是默认。

这就是为什么 Git 与 Worktree 工作流 —— 克隆一个仓库、推送一个智能体的分支 —— 通常在账户存在后就直接可用：凭据是在后台自动、按主机提供的。

值得了解

• 令牌留在设备上。 凭据存放在你操作系统的系统密钥环中（macOS 上是 Keychain，Windows 上是凭据管理器，Linux 上是 Secret Service），在没有可用密钥环的地方 —— 比如无头的服务器部署 —— 则有一个本地的 tokens.json 作为回退。只有账户的非机密元数据（服务器、用户名、权限范围）位于应用数据库中；机密本身从不在其中。
• 你添加的第一个账户会自动成为默认。 此后，设为默认 会移动它 —— 并且记住，默认只在同一服务器上区分账户，它并不是面向其他主机的通吃项。
• 移除账户会删除它的机密。 确认操作会移除该账户并从系统密钥环中清除它的令牌/密码 —— 不会有残留。
• Git 可执行文件和账户彼此独立。 设置自定义 git 路径不会触及你的账户，反之亦然；每个面板各自保存。
• 仓库任务在触发时就钉住它的账户。 仓库面板创建任务时，会记下哪个账户读取了这条工作项 —— 而不是「此刻默认的那个」。之后改动默认账户，无法改变它的分支以谁的身份被推送，这也正是更新令牌存在的意义：它保住那些任务所钉住的身份，而删掉再添加回来则不会。
• 与模型提供商不同。 这些是用于 Git 服务器 的凭据；你的智能体用来访问模型的 API 密钥位于模型提供商之下。两个独立的凭据存储，服务于两件独立的工作。

相关

• 仓库面板 —— 这些 GitHub 和 GitLab 账户所解锁的 issue 与 pull request 工作台。
• Git 与 Worktree —— 这些凭据在幕后默默支撑的应用内 git 工作流：差异比较、提交、分支和并行 worktree。
• 模型提供商 —— 另一个凭据界面，用于智能体的模型访问而非 Git 服务器。
• 系统 —— 网络代理，git 流量和其他一切都经由它。
• 参考概览 —— 完整的 14 个设置界面地图。