連接程式碼託管
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、讀取差異、行內與頂層留言、審查、合併與關閉。除此之外，它們確實各有差異，而 Control Center 會把託管平台做不到的事藏起來，而不是顯示一個會悄悄失敗的控制項。
| 能力 | GitHub | GitLab | Bitbucket |
|---|---|---|---|
| 批次（待送出）審查 | ✓ | ✓ | — |
| 要求變更 | ✓ | ✓ | ✓ |
| 每個檔案的「已檢視」狀態會同步 | ✓ | — | — |
| 表情回應 | ✓ | ✓ | — |
| 團隊／群組審查者 | ✓ | ✓ | — |
| 建議審查者 | ✓ | — | ✓ |
| 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 清單是空的，並顯示某個託管平台未連接」的章節你沒有那個託管平台的憑證。請在設定 → 工作區 → 個人資料與身分 → 程式碼託管中登入或貼上權杖。其他託管平台的儲存庫不受影響。
我連接了託管平台，但它的儲存庫仍然什麼都沒顯示
標題為「我連接了託管平台，但它的儲存庫仍然什麼都沒顯示」的章節檢查該列的副標題。如果它顯示「透過此伺服器的應用程式」或「來自環境變數」，就代表回應的不是你預期的那份憑證——凡是代表你提出的請求，都以你自己的憑證為優先，因此若顯示的不是這樣，就表示你的憑證沒有儲存成功。
儲存庫無法註冊
標題為「儲存庫無法註冊」的章節註冊需要同時滿足三項條件：路徑位於 git 工作樹內、具有 origin 遠端，且該遠端指向 github.com、gitlab.com 或 bitbucket.org。請見將儲存庫加入工作區。
大量使用之後，所有東西都會停擺一陣子
標題為「大量使用之後，所有東西都會停擺一陣子」的章節那是速率限制的斷路器。當某個託管平台發出已觸及主要限制的訊號時，用戶端會在本地直接讓後續請求失敗，不發出任何網路呼叫，直到該時間窗過去為止——因此重試風暴不會讓限制更加嚴重。暫時性失敗會以指數退避重試。