連接程式碼託管
Control Center 支援三個程式碼託管平台，應用程式中一律稱為託管平台：GitHub、GitLab 和 Bitbucket Cloud。三者都不是預設選項。連接其中一個，一切就能運作；連接多個，同一個工作區便能同時容納來自它們全部的程式庫。
託管平台是每個程式庫的一項屬性，在你註冊該程式庫時從它的 origin 遠端讀取。你永遠不需要挑選，也沒有任何按工作區劃分的設定可以出錯。
連接託管平台
標題為「連接託管平台」的章節- 開啟 設定 → 工作區 → 個人資料與身分（
/settings/workspace/profile）。 - 找到 程式碼託管 卡片。所有支援的託管平台都會列出，無論是否已連接。
- 若該列提供 使用 … 登入，就按下它；否則按 新增權杖，再貼上一個權杖。
登入只會出現在你的伺服器已為其註冊應用程式的託管平台上 —— 目前就是 GitHub，經由裝置流程（見建立 GitHub App）。其他一律是貼上的權杖，這是誠實的操作方式，而不是一顆無法完成的按鈕。
不論哪一種，憑證都是你的，並且存放在伺服器上，以你的使用者 id 為鍵：你輸入權杖的那部機器不會儲存任何權杖，你登入的每部裝置都使用同一個權杖，其他成員也讀不到。它會在下一個請求生效 —— 沒有東西需要重新啟動，而中斷連接後，它就會立即停止被送出。
每一列都會告訴你它的憑證來自哪裏，因為那正是「我的權杖沒有生效」與「回答的是另一個權杖」之間的差別：
| 副標題 | 含義 |
|---|---|
Signed in as octocat |
正在使用你自己的憑證 |
Signed in as octocat · via this server's app |
回答的是伺服器的應用程式身分 —— 你尚未登入 |
Signed in as octocat · from the environment |
回答的是伺服器環境變數，而不是你的憑證 |
Not connected |
你沒有這個託管平台的憑證 |
每個託管平台需要哪種權杖
標題為「每個託管平台需要哪種權杖」的章節| 託管平台 | 權杖 | 在哪裏建立 |
|---|---|---|
| GitHub | Classic：repo 與 read:org。Fine-grained：Contents + Pull requests（讀寫）、Checks + Actions（讀取） |
github.com → Settings → Developer settings → Tokens |
| GitLab | 具備 api 的個人存取權杖 |
gitlab.com → User settings → Access tokens |
| Bitbucket | Atlassian API 權杖，加上你的帳戶電郵 | id.atlassian.com → Security → API tokens |
Bitbucket 以你的帳戶電郵作為使用者名稱、以權杖作為密碼來驗證。請在伺服器環境中設定 BITBUCKET_EMAIL，它才知道要讓哪個電郵與該權杖配對。
或改用環境變數
標題為「或改用環境變數」的章節對於無介面或 CI 安裝，伺服器會讀取這些：
- GitHub —
GITHUB_TOKEN，然後GH_TOKEN - GitLab —
GITLAB_TOKEN，然後CI_JOB_TOKEN - Bitbucket —
BITBUCKET_API_TOKEN，然後BITBUCKET_TOKEN（連同BITBUCKET_EMAIL）
這些是伺服器的憑證，而不是你的，而且這個區別至關重要：以你的名義發出的請求只會使用你的憑證，不會用其他任何東西，所以環境永遠不會悄悄代替你。沒有人類在背後的工作 —— webhook、PR 輪詢、工單同步 —— 會先解析伺服器的應用程式身分，然後是伺服器擁有者的憑證，最後才是環境。這個順序是固定的，因此「我登入了，但甚麼都沒變」永遠不會是一種受支援的結果。
你在每個託管平台上都是另一個人
標題為「你在每個託管平台上都是另一個人」的章節同一個人在 GitHub 上是 octocat，在 GitLab 上則完全是另一個身分。Control Center 按託管平台解析你的身分，並為每個程式庫使用正確的那一個；這正是「有待我審查」、「由我建立」和「你已批准」在混合的工作區中依然正確的原因。
如果某個託管平台的身分尚未解析，它的程式庫就不會為收件箱貢獻任何內容，而不是比對到所有東西。收件箱會如實說明，而不是聲稱你已經全部看完。
一個收件箱，涵蓋每個託管平台
標題為「一個收件箱，涵蓋每個託管平台」的章節收件箱與 PR 佇列會分散查詢工作區中出現的每個託管平台，並把結果合併成單一資料流 —— 一個 GitHub pull request 和一個 Bitbucket pull request 會並排出現，按時間排序，而不是按供應商分組。
失敗是互相隔離的。某個託管平台若無法連線、受到速率限制或尚未連接，就不會貢獻任何內容，也不會影響其他平台；它永遠不會令整個收件箱變空。它自己的程式庫會繼續顯示最後已知的狀態，直到它恢復為止。
每個託管平台能做甚麼
標題為「每個託管平台能做甚麼」的章節每個託管平台都支援核心流程：列出並開啟 pull request、閱讀 diff、在行內與頂層留言、審查、合併與關閉。除此之外，它們確實各有不同，而 Control Center 會把託管平台做不到的事隱藏起來，而不是顯示一個會靜默失敗的控制項。
| 能力 | GitHub | GitLab | Bitbucket |
|---|---|---|---|
| 批次（待提交）審查 | ✓ | ✓ | — |
| 要求變更 | ✓ | ✓ | ✓ |
| 每個檔案的「已檢視」狀態同步 | ✓ | — | — |
| Emoji 反應 | ✓ | ✓ | — |
| 團隊／群組審查者 | ✓ | ✓ | — |
| 建議審查者 | ✓ | — | ✓ |
| PR 上的 CI 結果 | ✓ | ✓ | ✓ |
| 深入查看 CI 工作的步驟／日誌 | ✓ | ✓ | — |
| 堆疊式 pull request | ✓ | — | — |
| PR 描述範本 | ✓ | ✓ | — |
| 通知輪詢 | ✓ | — | — |
| 豐富的使用者個人資料 | ✓ | ✓ | — |
| 伺服器端 PR head ref | ✓ | ✓ | — |
當某項能力缺失時，功能會如實降級：
- 已檢視狀態仍然有效，但只限於你設定它的那部裝置。
- Bitbucket 上的批次審查會逐條留言送出，所以審查者會看到它們逐條抵達，而不是一次全部出現。
- Bitbucket 上沒有 PR head ref，意味着檢出一個 pull request 時會按名稱取得其來源分支，而該分支一旦被刪除就會失敗。
GitLab 把 pull request 稱為 merge request。Control Center 在自己的模型中一律說「pull request」，而在談到某個託管平台時，則使用該平台自己的名詞。
疑難排解
標題為「疑難排解」的章節PR 清單是空的，並說某個託管平台尚未連接
標題為「PR 清單是空的，並說某個託管平台尚未連接」的章節你沒有那個託管平台的憑證。請在 設定 → 工作區 → 個人資料與身分 → 程式碼託管 中登入或貼上權杖。其他託管平台的程式庫不受影響。
我連接了託管平台，但它的程式庫仍然甚麼都不顯示
標題為「我連接了託管平台，但它的程式庫仍然甚麼都不顯示」的章節檢查該列的副標題。如果它顯示「via this server’s app」或「from the environment」，那麼正在回答的就是另一個憑證，而不是你預期的那個 —— 你自己要求的一切都以你的憑證為優先，所以若它顯示的是別的，就代表你的憑證沒有儲存成功。
某個程式庫無法註冊
標題為「某個程式庫無法註冊」的章節註冊需要同時滿足三項：路徑位於 git 工作樹內、它有一個 origin 遠端，而且該遠端指向 github.com、gitlab.com 或 bitbucket.org。見將程式庫加入工作區。
大量使用後，一切都會停擺一陣子
標題為「大量使用後，一切都會停擺一陣子」的章節那是速率限制的斷路器。當某個託管平台發出已達主要限制的訊號，用戶端就會在本機令後續請求失敗，不發出網絡呼叫，直到該時窗過去 —— 因此重試風暴無法加深限制。暫時性失敗會以指數退避重試。