Einen Code-Host verbinden

Control Center arbeitet mit drei Code-Hosts — in der App heißen sie genau so: GitHub, GitLab und Bitbucket Cloud. Keiner davon ist die Vorgabe. Verbindest du einen, funktioniert alles; verbindest du mehrere, kann ein einzelner Arbeitsbereich Repos von allen gleichzeitig halten.

Der Code-Host ist eine Eigenschaft jedes Repos und wird beim Registrieren aus dem origin-Remote gelesen. Du wählst ihn nie selbst, und es gibt keine Einstellung je Arbeitsbereich, an der du etwas falsch machen kannst.

Einen Code-Host verbinden

Öffne Einstellungen → Arbeitsbereich → Profil und Identität (/settings/workspace/profile).
Finde die Karte Code-Hosting. Jeder unterstützte Code-Host steht dort, verbunden oder nicht.
Drücke Mit … anmelden, wenn die Zeile das anbietet, oder Token hinzufügen und füge eines ein.

Mit … anmelden erscheint bei einem Code-Host, für den dein Server eine App registriert hat — heute ist das GitHub, über einen Device-Flow (siehe Die GitHub App erstellen). Alles andere ist ein eingefügtes Token, weil sich eine Schaltfläche hier nicht zu Ende führen ließe.

So oder so ist das Zugangsdatum deins und liegt auf dem Server, gebunden an deine Benutzer-ID: Auf dem Rechner, auf dem du es eintippst, liegt kein Token, jedes Gerät, von dem du dich anmeldest, nutzt dasselbe, und kein anderes Mitglied kann es lesen. Es gilt ab der nächsten Anfrage — neu starten musst du nichts, und trennst du die Verbindung, wird es sofort nicht mehr gesendet.

Jede Zeile sagt, woher ihr Zugangsdatum kommt. Daran scheiden sich „mein Token funktioniert nicht“ und „ein anderes Token antwortet“:

Untertitel	Bedeutung
`Angemeldet als octocat`	Dein eigenes Zugangsdatum wird verwendet
`Angemeldet als octocat · über die App dieses Servers`	Die App-Identität des Servers antwortet — du bist nicht angemeldet
`Angemeldet als octocat · aus der Umgebung`	Eine Umgebungsvariable des Servers antwortet, nicht dein Zugangsdatum
`Nicht verbunden`	Du hast für diesen Code-Host kein Zugangsdatum

Welches Token welcher Code-Host braucht

Code-Host	Token	Wo du es anlegst
GitHub	Classic: `repo` und `read:org`. Fine-grained: Contents + Pull requests (read/write), Checks + Actions (read)	github.com → Settings → Developer settings → Tokens
GitLab	Ein persönliches Zugriffstoken mit `api`	gitlab.com → User settings → Access tokens
Bitbucket	Ein Atlassian-API-Token plus die E-Mail deines Kontos	id.atlassian.com → Security → API tokens

Bitbucket authentifiziert mit deiner Konto-E-Mail als Benutzername und dem Token als Passwort. Setze BITBUCKET_EMAIL in der Umgebung des Servers, damit er weiß, welche E-Mail zum Token gehört.

Oder die Umgebung nutzen

Bei einer Headless- oder CI-Installation liest der Server diese Werte:

GitHub — GITHUB_TOKEN, dann GH_TOKEN
GitLab — GITLAB_TOKEN, dann CI_JOB_TOKEN
Bitbucket — BITBUCKET_API_TOKEN, dann BITBUCKET_TOKEN (mit BITBUCKET_EMAIL)

Das sind die Zugangsdaten des Servers, nicht deine, und daran hängt, wer antwortet: Eine Anfrage in deinem Auftrag nutzt dein Zugangsdatum und sonst nichts. Die Umgebung springt also nie still für dich ein. Arbeit ohne Menschen dahinter — Webhooks, PR-Polling, Ticket-Sync — löst zuerst die App-Identität des Servers auf, dann das Zugangsdatum des Server-Eigentümers, dann die Umgebung. Die Reihenfolge steht fest, damit „Ich habe mich angemeldet und nichts hat sich geändert“ nie ein unterstütztes Ergebnis ist.

Auf jedem Code-Host bist du eine andere Person

Derselbe Mensch ist auf GitHub octocat und auf GitLab jemand ganz anderes. Control Center löst deine Identität je Code-Host auf und nimmt für jedes Repo die passende. Erst dadurch stimmen „braucht mein Review“, „von mir erstellt“ und „du hast das genehmigt“ in einem gemischten Arbeitsbereich.

Ist die Identität eines Code-Hosts noch nicht aufgelöst, tragen seine Repos nichts zum Posteingang bei, statt auf alles zu passen. Der Posteingang sagt das, statt zu behaupten, du seist auf dem neuesten Stand.

Ein Posteingang, jeder Code-Host

Posteingang und PR-Warteschlange fragen jeden Code-Host ab, der im Arbeitsbereich vorkommt, und führen die Ergebnisse zu einem Strom zusammen — ein Pull Request von GitHub und einer von Bitbucket stehen nebeneinander, nach Zeit geordnet statt nach Anbieter gruppiert.

Ausfälle bleiben isoliert. Ein Code-Host, der ausfällt, am Rate-Limit hängt oder nicht verbunden ist, trägt nichts bei und lässt die anderen in Ruhe; den ganzen Posteingang leert er dabei nie. Seine eigenen Repos zeigen weiter den letzten bekannten Stand, bis er wieder da ist.

Was jeder Code-Host kann

Jeder Code-Host trägt die Kernschleife: Pull Requests auflisten und öffnen, Diffs lesen, inline und auf der obersten Ebene kommentieren, ein Review abgeben, mergen und schließen. Darüber hinaus unterscheiden sie sich wirklich, und Control Center blendet aus, was ein Code-Host nicht kann, statt eine Steuerung zu zeigen, die still fehlschlägt.

Fähigkeit	GitHub	GitLab	Bitbucket
Gebündelte (ausstehende) Reviews	✓	✓	—
Änderungen anfordern	✓	✓	✓
„Angesehen“-Status pro Datei, synchronisiert	✓	—	—
Emoji-Reaktionen	✓	✓	—
Team- oder Gruppen-Reviewer	✓	✓	—
Vorgeschlagene Prüfer	✓	—	✓
CI-Ergebnisse an einem PR	✓	✓	✓
Schritte und Logs eines CI-Jobs aufklappen	✓	✓	—
Gestapelte Pull Requests	✓	—	—
Vorlagen für die PR-Beschreibung	✓	✓	—
Abruf von Benachrichtigungen	✓	—	—
Ausführliche Nutzerprofile	✓	✓	—
Serverseitige PR-Head-Ref	✓	✓	—

Fehlt eine Fähigkeit, baut die Funktion ehrlich ab:

Der Status „angesehen“ funktioniert weiter, aber nur auf dem Gerät, auf dem du ihn gesetzt hast.
Gebündelte Reviews auf Bitbucket gehen Kommentar für Kommentar raus, Reviewer sehen sie also einzeln ankommen statt alle auf einmal.
Keine PR-Head-Ref auf Bitbucket heißt: Beim Auschecken eines Pull Requests wird der Quell-Branch über den Namen geholt, und das scheitert, sobald der Branch gelöscht ist.

Begriffe

GitLab nennt einen Pull Request Merge Request. Control Center sagt im eigenen Modell durchgängig „Pull Request“ und nutzt das Wort des jeweiligen Code-Hosts, wo es über genau diesen Code-Host spricht.

Fehlersuche

Die PR-Liste ist leer und meldet, ein Code-Host sei nicht verbunden

Du hast für diesen Code-Host kein Zugangsdatum. Melde dich an oder füge unter Einstellungen → Arbeitsbereich → Profil und Identität → Code-Hosting ein Token ein. Die Repos der anderen Code-Hosts bleiben unberührt.

Ich habe einen Code-Host verbunden, seine Repos zeigen aber nichts

Prüfe den Untertitel der Zeile. Steht dort „über die App dieses Servers“ oder „aus der Umgebung“, antwortet ein anderes Zugangsdatum als das, das du erwartest. Für alles, was du anfragst, gewinnt dein eigenes. Steht dort also etwas anderes, wurde deins nicht gespeichert.

Ein Repo lässt sich nicht registrieren

Zur Registrierung müssen alle drei gelten: Der Pfad liegt in einem Git-Arbeitsbaum, er hat ein origin-Remote, und dieses Remote zeigt auf github.com, gitlab.com oder bitbucket.org. Siehe Repos zu einem Arbeitsbereich hinzufügen.

Nach starker Nutzung steht eine Weile alles still

Das ist der Schutzschalter für das Rate-Limit. Meldet ein Code-Host sein primäres Limit, lässt der Client weitere Anfragen lokal scheitern, ohne Netzwerkaufruf, bis das Fenster abgelaufen ist — eine Flut von Wiederholungen kann das Limit so nicht weiter verschärfen. Vorübergehende Fehler werden mit exponentiellem Backoff erneut versucht.

Einen Code-Host verbinden