Cosa sono le content exclusions

Le content exclusions sono una policy amministrativa che indica a GitHub Copilot di non usare determinati file o path come contesto. Servono a tenere fuori dal motore di suggerimento porzioni di codice sensibili o rumorose: file di configurazione con endpoint interni, template proprietari, cartelle generate, snippet coperti da vincoli contrattuali. L’obiettivo è ridurre la superficie di contesto, non nascondere il file dal repository (il file resta versionato e leggibile normalmente in Git e nell’editor).

Quando un path è escluso, Copilot applica due comportamenti:

  • Nessun completamento viene offerto mentre stai editando quel file.
  • Il contenuto di quel file non alimenta i suggerimenti generati in altri file aperti né le risposte di Copilot Chat.

Dove si configurano

Le exclusions sono un controllo top-down, disponibile solo sui piani GitHub Copilot Business e GitHub Copilot Enterprise. Non esistono per i piani individuali (Free/Pro): un singolo sviluppatore non può auto-escludersi file.

Livello repository

Un amministratore del repo le imposta in Settings → Copilot → Content exclusion, elencando i path con pattern in stile fnmatch (supporto a * e **):

"*":
  - "/secrets/**"
  - "**/*.env"
  - "/config/prod-settings.json"

Qui la chiave "*" significa “tutte le fonti”; sotto stanno i path da escludere all’interno di quel repository.

Livello organizzazione (ed enterprise)

Gli org owner definiscono regole che valgono trasversalmente, indicizzate per repository. Questo è lo strato giusto quando la stessa cartella va esclusa in decine di progetti, o quando vuoi coprire repo che i team creeranno in futuro:

"*":
  - "/internal-docs/**"
"https://github.com/contoso/payments":
  - "/src/keys/**"

Le regole di org e di repo si sommano: un path escluso a livello organizzazione resta escluso anche se il singolo repo non lo elenca.

Cosa succede alle superfici

Le exclusions sono pensate soprattutto per le superfici IDE (VS Code, Visual Studio, JetBrains, Vim/Neovim): lì Copilot verifica i pattern prima di comporre il contesto. La copertura però non è uniforme su ogni superficie: alcune esperienze (per esempio parti di Copilot su GitHub.com, in Copilot CLI o su GitHub Mobile) storicamente non applicano le stesse esclusioni. In sede d’esame conta ricordare che l’efficacia dipende dal client e che la propagazione non è istantanea.

Limiti da conoscere

  • Propagazione ritardata. Una modifica alle exclusions può richiedere fino a circa 30 minuti per riflettersi, e i file già aperti in editor possono continuare a essere usati come contesto finché non ricarichi la finestra. Non è un blocco a effetto immediato.
  • Non è un controllo di sicurezza. Le exclusions riducono l’uso come contesto ma non garantiscono che quel contenuto non influenzi mai un suggerimento, e non sostituiscono i controlli di accesso. I segreti non vanno gestiti con le exclusions: la risposta corretta è non committarli, usare secret scanning / push protection e un secret manager.
  • Solo Business/Enterprise. Sono una leva di governance amministrativa; a livello di singolo utente non sono disponibili.
  • Semantica ridotta. Escludendo file, Copilot perde visibilità su quelle parti del codebase: i suggerimenti su moduli correlati possono diventare meno accurati. È un trade-off tra riservatezza del contesto e qualità del completamento.

Trappole tipiche d’esame

  • Scenario: uno sviluppatore con piano Copilot Pro individuale vuole escludere una cartella dal contesto. → Risposta: non è possibile; le content exclusions richiedono Copilot Business o Enterprise e si configurano a livello repo/org, non dal singolo utente.
  • Scenario: subito dopo aver aggiunto una regola, Copilot suggerisce ancora dal file “escluso” tuttora aperto. → Risposta: comportamento atteso: la modifica può impiegare fino a circa 30 minuti e i file già aperti richiedono un reload; non è un malfunzionamento.
  • Scenario: un team vuole impedire in modo assoluto che le API key finiscano nei suggerimenti. → Risposta: le exclusions non sono un controllo di sicurezza; usare secret scanning/push protection e non committare i segreti.
  • Scenario: la stessa cartella va esclusa in tutti i repo dell’azienda, presenti e futuri. → Risposta: configurarla a livello organizzazione (regole con "*"), non repo per repo.
  • Scenario: un utente nota che l’esclusione funziona nell’IDE ma non in un’altra superficie Copilot. → Risposta: la copertura varia per superficie; le exclusions sono garantite soprattutto sugli IDE supportati.