Public, private e internal: chi vede il repository

La visibility di un repository decide chi può leggerne il codice e si imposta alla creazione oppure più tardi da Settings. Un repository public è accessibile a chiunque visiti GitHub, e chiunque può crearne un fork. Un repository private è visibile solo a chi viene invitato come collaborator e a chi amministra l’account che lo ospita. Un repository internal è visibile a tutti i membri delle organizzazioni che appartengono allo stesso enterprise account: esiste quindi solo dentro un enterprise, mai in un account personale.

Internal è la base tecnica dell’InnerSource, cioè applicare i metodi dell’open source dentro l’azienda: il codice resta chiuso verso l’esterno, ma qualunque collega può trovarlo, leggerlo, aprire una issue o proporre una pull request. La documentazione consiglia di accompagnarlo con base permissions almeno di livello read sull’organizzazione, README curati e topics, perché senza discoverability l’InnerSource non decolla.

Cambiare visibility non è un’operazione neutra. Passando a public le push rulesets vengono disattivate e la cronologia dei workflow diventa leggibile da tutti; passando da public a private i fork esistenti restano pubblici e vengono staccati dal repository di origine; in diversi passaggi stelle e watcher vengono azzerati. Per questo un organization owner può limitare in Member privileges chi ha il diritto di cambiare visibility: solo gli owner, oppure chiunque abbia admin sul repository.

Branch protection rule e ruleset

Il branch predefinito si protegge in due modi che oggi convivono. La branch protection rule classica applica a un pattern di branch requisiti come required pull request reviews con un numero minimo di approvazioni, required status checks che devono passare prima del merge, la risoluzione delle conversazioni, la linear history, i signed commits, la restrizione su chi può fare push e il blocco di force push e cancellazione. Il limite storico è che a un branch si applica una sola branch protection rule alla volta.

I rulesets sono l’evoluzione. Sono liste di regole con un nome, agiscono su branch e tag, possono includere push rules e soprattutto più ruleset possono insistere sullo stesso branch: in quel caso le regole si sommano e vince la versione più restrittiva. Un ruleset ha uno stato di enforcement che si può disattivare senza cancellarlo, ha una bypass list con utenti, team, ruoli o GitHub App autorizzati a scavalcarlo, ed è consultabile da chiunque abbia accesso in lettura, il che rende trasparenti le regole a chi contribuisce. Rulesets e branch protection rules possono coesistere sullo stesso branch e vengono valutati insieme.

Che cosa verifica l’esame qui: che tu sappia riconoscere il vantaggio dichiarato dei ruleset, cioè la sovrapposizione, e che le protezioni si applicano al branch, non alla persona. La confusione tipica è credere che una regola “vieti il push a un utente”: definisce invece le condizioni per aggiornare quel branch, e per impostazione predefinita chi ha admin può aggirarla, a meno che la restrizione non venga estesa anche agli amministratori.

Enterprise Managed Users: gli account li crea l’identity provider

Con gli Enterprise Managed Users, spesso abbreviati in EMU, il ciclo di vita degli account non è più nelle mani delle persone. L’identity provider aziendale crea gli utenti su GitHub tramite provisioning SCIM e li autentica con SAML o OIDC; da lì si governano username, dati del profilo, appartenenza alle organizzazioni e accesso ai repository. Disattivare la persona nell’IdP la disattiva anche su GitHub.

Un managed user account è confinato all’enterprise: come repository personali può creare solo private, dentro le organizzazioni si creano solo repository private e internal, non può creare repository public, non può forkare, mettere stelle o seguire persone fuori dall’enterprise, non può creare o commentare gist e non può aprire issue, pull request o discussion nei repository pubblici. Verso il resto di GitHub ha di fatto sola lettura ed è visibile solo agli altri membri dell’enterprise.

Confusione da evitare: attivare il single sign-on su un’organizzazione non è EMU. Con il SAML tradizionale la persona continua a usare il proprio account personale, che le appartiene; con EMU l’account è creato e posseduto dall’enterprise ed è separato da qualsiasi identità pubblica.

Le policy Copilot a livello di organizzazione

Un organization owner gestisce nelle impostazioni dell’organizzazione le policy di GitHub Copilot, divise fra la scheda che regola privacy e disponibilità delle funzionalità e quella che regola i modelli disponibili. Fra le voci più citate ci sono Copilot su GitHub.com, Copilot Chat, code review, la CLI, gli agenti di terze parti, i server MCP e l’impostazione suggestions matching public code, che decide se accettare suggerimenti che coincidono con codice pubblico.

La gerarchia è il punto che l’esame ama chiedere: se un enterprise owner ha già scelto una policy, abilitandola o disabilitandola ovunque oppure solo per alcune organizzazioni, l’organizzazione non la può sovrascrivere. L’owner dell’organizzazione decide soltanto dove l’enterprise gli ha lasciato spazio.