Conectează un host de cod

Control Center funcționează cu trei hosturi de cod, numite forge-uri în toată aplicația: GitHub, GitLab și Bitbucket Cloud. Niciunul nu este implicit. Conectează unul și totul funcționează; conectează mai multe și un singur spațiu de lucru poate conține repo-uri din toate deodată.

Forge-ul este o proprietate a fiecărui repo, citită din remote-ul origin atunci când îl înregistrezi. Nu îl alegi niciodată și nu există nicio setare la nivel de spațiu de lucru pe care să o poți greși.

Conectează un forge

Deschide Setări → Spațiu de lucru → Profil și identitate (/settings/workspace/profile).
Găsește cardul Găzduire de cod. Fiecare forge acceptat este listat, conectat sau nu.
Apasă Autentifică-te cu … dacă rândul îl oferă, sau Adaugă token și lipește unul.

Autentificarea apare pentru un forge pentru care serverul tău are o aplicație înregistrată — astăzi, acesta este GitHub, printr-un flux de dispozitiv (vezi Creează GitHub App). Pentru orice altceva, tokenul se lipește, ceea ce este alternativa onestă, nu un buton care nu se poate finaliza.

În ambele cazuri, acreditarea este a ta și se află pe server, indexată după id-ul tău de utilizator: niciun token nu este stocat pe mașina pe care l-ai introdus, fiecare dispozitiv de pe care te autentifici o folosește pe aceeași, iar niciun alt membru nu o poate citi. Ea intră în vigoare la următoarea cerere — nu este nimic de repornit, iar deconectarea oprește imediat trimiterea ei.

Fiecare rând îți spune de unde provine acreditarea sa, pentru că aceasta este diferența dintre „tokenul meu nu funcționează” și „răspunde un alt token”:

Subtitlu	Semnificație
`Signed in as octocat`	Se folosește propria ta acreditare
`Signed in as octocat · via this server's app`	Răspunde identitatea de aplicație a serverului — nu te-ai autentificat
`Signed in as octocat · from the environment`	Răspunde o variabilă de mediu a serverului, nu acreditarea ta
`Not connected`	Nu ai nicio acreditare pentru acest forge

Ce token cere fiecare forge

Forge	Token	Unde îl creezi
GitHub	Clasic: `repo` și `read:org`. Cu granularitate fină: Contents + Pull requests (citire/scriere), Checks + Actions (citire)	github.com → Settings → Developer settings → Tokens
GitLab	Un token de acces personal cu `api`	gitlab.com → User settings → Access tokens
Bitbucket	Un token API Atlassian, plus adresa de e-mail a contului tău	id.atlassian.com → Security → API tokens

Bitbucket se autentifică folosind adresa de e-mail a contului ca nume de utilizator și tokenul ca parolă. Setează BITBUCKET_EMAIL în mediul serverului, ca să știe cu ce adresă de e-mail să asocieze tokenul.

Sau folosește variabilele de mediu

Pentru o instalare headless sau CI, serverul citește acestea:

GitHub — GITHUB_TOKEN, apoi GH_TOKEN
GitLab — GITLAB_TOKEN, apoi CI_JOB_TOKEN
Bitbucket — BITBUCKET_API_TOKEN, apoi BITBUCKET_TOKEN (cu BITBUCKET_EMAIL)

Acestea sunt acreditările serverului, nu ale tale, iar distincția este esențială: o cerere făcută în numele tău folosește acreditarea ta și nimic altceva, așa că mediul nu te înlocuiește niciodată pe nesimțite. Munca fără niciun om în spate — webhook-uri, interogarea periodică a PR-urilor, sincronizarea tichetelor — rezolvă mai întâi identitatea de aplicație a serverului, apoi acreditarea proprietarului serverului, apoi mediul. Ordinea este fixă, astfel încât „m-am autentificat și nimic nu s-a schimbat” să nu fie niciodată un rezultat posibil.

Ești o altă persoană pe fiecare forge

Aceeași persoană este octocat pe GitHub și cu totul altceva pe GitLab. Control Center îți rezolvă identitatea pe fiecare forge și o folosește pe cea potrivită pentru fiecare repo, iar asta face ca „necesită revizuirea mea”, „creat de mine” și „ai aprobat asta” să fie corecte într-un spațiu de lucru mixt.

Dacă identitatea unui forge nu s-a rezolvat, repo-urile lui nu contribuie cu nimic la inbox, în loc să se potrivească cu tot. Inboxul spune asta în loc să afirme că ești la zi cu tot.

Un singur inbox, toate forge-urile

Inboxul și coada de PR-uri se ramifică spre toate forge-urile reprezentate în spațiul de lucru și îmbină rezultatele într-un singur flux — un pull request GitHub și un pull request Bitbucket stau unul lângă altul, ordonate după timp, nu grupate după furnizor.

Eșecurile sunt izolate. Un forge care este picat, limitat de rată sau neconectat nu contribuie cu nimic și nu le afectează pe celelalte; nu golește niciodată tot inboxul. Repo-urile lui continuă să afișeze ultima stare cunoscută până când își revine.

Ce poate face fiecare forge

Fiecare forge acceptă bucla de bază: listează și deschide pull request-uri, citește diff-uri, comentează inline și la nivel superior, revizuiește, îmbină și închide. Dincolo de asta, ele chiar diferă, iar Control Center ascunde ce nu poate face un forge în loc să afișeze un control care eșuează în tăcere.

Capabilitate	GitHub	GitLab	Bitbucket
Revizuiri grupate (în așteptare)	✓	✓	—
Cere modificări	✓	✓	✓
Starea „vizualizat” pe fișier, sincronizată	✓	—	—
Reacții emoji	✓	✓	—
Recenzenți de echipă / grup	✓	✓	—
Recenzenți sugerați	✓	—	✓
Rezultate CI pe un PR	✓	✓	✓
Pătrundere în pașii/jurnalele unui job CI	✓	✓	—
Pull request-uri stivuite	✓	—	—
Șabloane de descriere a PR-urilor	✓	✓	—
Interogare periodică a notificărilor	✓	—	—
Profiluri de utilizator bogate	✓	✓	—
Ref-ul head al PR-ului, pe server	✓	✓	—

Acolo unde lipsește o capabilitate, funcționalitatea se degradează onest:

Starea „vizualizat” funcționează în continuare, dar doar pe dispozitivul pe care ai setat-o.
Revizuirile grupate pe Bitbucket se publică comentariu cu comentariu, așa că recenzenții le văd sosind individual, nu pe toate deodată.
Fără ref de head al PR-ului pe Bitbucket, checkoutul unui pull request aduce ramura sursă după nume, ceea ce eșuează după ce ramura respectivă este ștearsă.

Vocabular

GitLab numește un pull request merge request. Control Center spune „pull request” în tot modelul propriu și folosește substantivul propriu al fiecărui forge atunci când vorbește despre acel forge.

Depanare

Lista de PR-uri este goală și spune că un forge nu este conectat

Nu ai nicio acreditare pentru acel forge. Autentifică-te sau lipește un token în Setări → Spațiu de lucru → Profil și identitate → Găzduire de cod. Repo-urile celorlalte forge-uri nu sunt afectate.

Am conectat un forge, dar repo-urile lui tot nu afișează nimic

Verifică subtitlul rândului. Dacă scrie „via this server’s app” sau „from the environment”, răspunde o altă acreditare decât cea la care te așteptai — acreditarea ta are prioritate pentru orice ceri tu, așa că, dacă scrie altfel, a ta nu a fost salvată.

Un repo nu se înregistrează

Înregistrarea are nevoie de toate trei: calea să fie într-un arbore de lucru git, repo-ul să aibă un remote origin, iar acel remote să indice spre github.com, gitlab.com sau bitbucket.org. Vezi Adaugă repo-uri într-un spațiu de lucru.

Totul se oprește o vreme după o utilizare intensă

Acesta este întrerupătorul de circuit pentru limita de rată. Un forge care își semnalează limita principală face clientul să respingă local cererile următoare, fără niciun apel de rețea, până când expiră fereastra — astfel încât o furtună de reîncercări nu poate adânci limita. Eșecurile tranzitorii sunt reîncercate cu backoff exponențial.