Il personal account: l’identità con cui si accede
Ogni persona che usa GitHub entra con un personal account: è l’identità individuale, con uno username univoco e un profilo che racconta il proprio lavoro attraverso repository e gist in evidenza. Un personal account può possedere repository pubblici e privati, gist, package e project, e resta l’unico tipo di account con cui si effettua davvero il login. Né un’organizzazione né un enterprise hanno credenziali proprie: ogni azione compiuta al loro interno è attribuita al personal account della persona che l’ha eseguita, ed è su quell’account che si configurano password, two-factor authentication e passkey.
La documentazione consiglia di usare un solo personal account per tutto il proprio lavoro, anche quando si collabora con più realtà: lo stesso account può appartenere contemporaneamente a molte organizzazioni e a molti team. Sui repository posseduti da un personal account esistono solo due figure, il proprietario e i collaborator che invita: non c’è la scala di ruoli intermedi tipica delle organizzazioni. Sul piano commerciale un personal account parte da GitHub Free e può passare a GitHub Pro, che sblocca funzionalità aggiuntive sui repository privati.
Che cosa verifica l’esame su questo punto: la confusione più frequente è immaginare l’organizzazione come “un account con cui si fa login”. Non lo è. Se una domanda parla di autenticazione, di 2FA o di recupero dell’accesso, il soggetto è sempre il personal account.
L’organization: chi possiede davvero i repository
Un’organization è un account condiviso in cui aziende e progetti open source collaborano su molti repository insieme. La differenza sostanziale rispetto al livello precedente è la proprietà: i repository appartengono all’organizzazione, non alla persona che li ha creati. Quando qualcuno lascia l’azienda, il codice resta dove si trova e basta revocare l’appartenenza.
Le persone entrano nell’organizzazione con il proprio personal account e ricevono un ruolo. I principali sono organization owner, che ha accesso amministrativo completo, e organization member, il ruolo predefinito con permessi limitati. Esistono poi ruoli specializzati da assegnare a chi serve: moderator per bloccare contributori esterni e nascondere commenti, billing manager per le sole impostazioni di fatturazione, security manager per gli alert e le impostazioni di sicurezza trasversali, GitHub App manager per le registrazioni delle app. Chi lavora su uno o più repository senza essere membro è un outside collaborator. I piani disponibili a questo livello sono GitHub Free for organizations e GitHub Team.
Team, base permissions e ruoli sui repository
Dentro un’organizzazione l’accesso non si concede una persona alla volta, ma tramite i team, gruppi che riflettono la struttura reale del gruppo di lavoro. I team possono essere annidati: un child team eredita automaticamente gli accessi del parent team, quindi assegnare un permesso in alto nella gerarchia lo fa scendere a cascata. I team servono anche per le menzioni, e possono essere visible, quindi visibili e menzionabili da tutti i membri, oppure secret, visibili solo a chi ne fa parte e agli owner e non annidabili.
Il livello di accesso a un singolo repository si esprime con i repository role: read per chi vuole solo consultare e discutere, triage per chi gestisce issue, discussion e pull request senza poter scrivere codice, write per chi contribuisce attivamente, maintain per chi amministra il progetto senza toccare azioni distruttive, admin per il controllo totale. A monte l’owner può fissare le base permissions, cioè il livello minimo che tutti i membri hanno su ogni repository dell’organizzazione; non si applicano agli outside collaborator, e un permesso più alto concesso a una persona o a un team prevale sulla base.
Confusione tipica da evitare all’esame: triage e write sembrano simili ma non lo sono. Triage permette di etichettare, chiudere e riaprire issue e pull request, non di fare push.
L’enterprise account: policy e amministrazione centralizzate
L’enterprise account sta un livello ancora più in alto e non possiede direttamente i repository: raggruppa più organizzazioni per gestirne in modo centrale policy e fatturazione, e per abilitare l’innersource tra di esse. I ruoli tipici sono enterprise owner ed enterprise member. Le due modalità di distribuzione sono GitHub Enterprise Cloud, ospitato da GitHub, e GitHub Enterprise Server, installato dal cliente sulla propria infrastruttura.
Merita attenzione Enterprise Managed Users: con questa modalità gli account non vengono creati dalle persone ma provisionati da un identity provider esterno, che controlla username, dati di profilo, appartenenza alle organizzazioni e accesso ai repository. Gli account gestiti non possono creare contenuti pubblici né collaborare fuori dall’enterprise. È l’alternativa all’enterprise classico, in cui le persone continuano a usare il proprio personal account autonomo.