Collega un host di codice

Control Center funziona con tre host di codice, chiamati forge in tutta l’app: GitHub, GitLab e Bitbucket Cloud. Nessuno di essi è quello predefinito. Collegane uno e tutto funziona; collegali tutti e un unico spazio di lavoro può ospitare contemporaneamente repo di ciascuno di essi.

Il forge è una proprietà di ogni repo, letto dal suo remote origin quando lo registri. Non lo scegli mai tu e non esiste un’impostazione per spazio di lavoro su cui sbagliarsi.

Collega un forge

Apri Impostazioni → Spazio di lavoro → Profilo e identità (/settings/workspace/profile).
Trova la scheda Hosting del codice. Ogni forge supportato è elencato, connesso o no.
Premi Accedi con … se la riga lo offre, oppure Aggiungi token e incollane uno.

Accedi compare per un forge per cui il tuo server ha un’app registrata — oggi è GitHub, tramite un device flow (vedi Crea la GitHub App). Tutto il resto è un token incollato, che è l’affordance onesta invece di un pulsante che non può portare a termine l’operazione.

In ogni caso la credenziale è tua e risiede sul server, indicizzata per il tuo id utente: nessun token viene memorizzato sulla macchina su cui l’hai digitato, ogni dispositivo da cui accedi usa lo stesso, e nessun altro membro può leggerlo. Ha effetto dalla richiesta successiva — non c’è nulla da riavviare, e la disconnessione ne interrompe immediatamente l’invio.

Ogni riga ti dice da dove proviene la sua credenziale, perché è la differenza tra «il mio token non funziona» e «sta rispondendo un token diverso»:

Sottotitolo	Significato
`Signed in as octocat`	Viene usata la tua credenziale
`Signed in as octocat · via this server's app`	Risponde l’identità applicativa del server — tu non hai effettuato l’accesso
`Signed in as octocat · from the environment`	Risponde una variabile d’ambiente del server, non la tua credenziale
`Not connected`	Non hai alcuna credenziale per questo forge

Quale token vuole ogni forge

Forge	Token	Dove crearlo
GitHub	Classico: `repo` e `read:org`. Fine-grained: Contents + Pull requests (read/write), Checks + Actions (read)	github.com → Settings → Developer settings → Tokens
GitLab	Un personal access token con `api`	gitlab.com → User settings → Access tokens
Bitbucket	Un token API Atlassian, più l’email del tuo account	id.atlassian.com → Security → API tokens

Bitbucket si autentica con la tua email dell’account come nome utente e il token come password. Imposta BITBUCKET_EMAIL nell’ambiente del server, così sa quale email abbinare al token.

Oppure usa l’ambiente

Per un’installazione headless o CI, il server legge queste:

GitHub — GITHUB_TOKEN, poi GH_TOKEN
GitLab — GITLAB_TOKEN, poi CI_JOB_TOKEN
Bitbucket — BITBUCKET_API_TOKEN, poi BITBUCKET_TOKEN (con BITBUCKET_EMAIL)

Queste sono credenziali del server, non tue, e la distinzione è determinante: una richiesta fatta a tuo nome usa la tua credenziale e nient’altro, così l’ambiente non ti sostituisce mai di nascosto. Il lavoro senza un umano dietro — webhook, polling delle PR, sincronizzazione dei ticket — risolve prima l’identità applicativa del server, poi la credenziale del proprietario del server, infine l’ambiente. L’ordine è fisso, così «ho effettuato l’accesso e non è cambiato nulla» non è mai un esito ammesso.

Sei una persona diversa su ogni forge

La stessa persona è octocat su GitHub e qualcosa di completamente diverso su GitLab. Control Center risolve la tua identità per forge e usa quella giusta per ogni repo, ed è ciò che rende corretti «richiede la mia revisione», «creato da me» e «l’hai approvato» in uno spazio di lavoro misto.

Se l’identità di un forge non è stata risolta, i suoi repo non contribuiscono nulla alla posta in arrivo invece di corrispondere a tutto. La posta in arrivo lo dice, invece di affermare che sei in pari con tutto.

Una sola posta in arrivo, ogni forge

La posta in arrivo e la coda delle PR si diramano su ogni forge rappresentato nello spazio di lavoro e uniscono i risultati in un unico flusso — una pull request di GitHub e una di Bitbucket stanno una accanto all’altra, ordinate per tempo invece che raggruppate per fornitore.

I guasti sono isolati. Un forge inattivo, soggetto a rate limit o non connesso non contribuisce nulla e lascia gli altri intatti; non svuota mai l’intera posta in arrivo. I suoi repo continuano a mostrare il loro ultimo stato noto finché non si riprende.

Cosa può fare ogni forge

Ogni forge supporta il ciclo principale: elenca e apri pull request, leggi i diff, commenta inline e a livello superiore, revisiona, unisci e chiudi. Oltre a questo differiscono davvero, e Control Center nasconde ciò che un forge non sa fare invece di mostrare un controllo che fallisce in silenzio.

Capacità	GitHub	GitLab	Bitbucket
Revisioni raggruppate (in sospeso)	✓	✓	—
Richiedi modifiche	✓	✓	✓
Stato «visualizzato» per file sincronizzato	✓	—	—
Reazioni emoji	✓	✓	—
Revisori di team / gruppo	✓	✓	—
Revisori suggeriti	✓	—	✓
Risultati CI su una PR	✓	✓	✓
Approfondisci passaggi/log di un job CI	✓	✓	—
Pull request in stack	✓	—	—
Modelli di descrizione delle PR	✓	✓	—
Polling delle notifiche	✓	—	—
Profili utente ricchi	✓	✓	—
Head ref della PR lato server	✓	✓	—

Dove manca una capacità, la funzionalità si degrada in modo onesto:

Lo stato visualizzato funziona comunque, ma solo sul dispositivo su cui l’hai impostato.
Le revisioni raggruppate su Bitbucket pubblicano commento per commento, così i revisori li vedono arrivare singolarmente invece che tutti insieme.
L’assenza di un head ref della PR su Bitbucket significa che fare il checkout di una pull request recupera il suo branch di origine per nome, il che fallisce una volta che quel branch è stato eliminato.

Vocabolario

GitLab chiama la pull request merge request. Control Center dice «pull request» in tutto il suo modello e usa il sostantivo proprio di ogni forge quando parla di quel forge.

Risoluzione dei problemi

L’elenco delle PR è vuoto e dice che un forge non è connesso

Non hai alcuna credenziale per quel forge. Accedi o incolla un token in Impostazioni → Spazio di lavoro → Profilo e identità → Hosting del codice. I repo degli altri forge non sono interessati.

Ho collegato un forge ma i suoi repo non mostrano ancora nulla

Controlla il sottotitolo della riga. Se dice «tramite l’app di questo server» o «dall’ambiente», sta rispondendo una credenziale diversa da quella che ti aspettavi — la tua credenziale vince per qualunque cosa tu chieda, quindi se dice altrimenti la tua non è stata salvata.

Un repo non si registra

La registrazione richiede tutte e tre le condizioni: il percorso è dentro un git work tree, ha un remote origin e quel remote punta a github.com, gitlab.com o bitbucket.org. Vedi Aggiungi repo a uno spazio di lavoro.

Tutto smette di funzionare per un po’ dopo un uso intenso

È l’interruttore di circuito del rate limit. Un forge che segnala il suo limite primario fa fallire localmente le ulteriori richieste del client, senza chiamate di rete, finché la finestra non trascorre — così una tempesta di tentativi non può aggravare il limite. I guasti transitori vengono ritentati con backoff esponenziale.