La risposta breve
GitLab non ha un’unica impostazione email. Ne ha diverse, e controllano cose differenti: l’indirizzo con cui accedi, quello mostrato sul profilo pubblico e quello allegato ai commit che firmi. Ritirare un indirizzo in modo sicuro significa controllare ogni superficie, perché modificarne una non pulisce automaticamente le altre.
L’email primaria di GitLab è quella predefinita per accesso, commit e notifiche; cambiandola, il vecchio indirizzo primario resta come indirizzo secondario. Fonte
Questa singola frase crea già una trappola. Se cambi l’email primaria con un nuovo indirizzo, il vecchio non scompare dal tuo account. Resta allegato come indirizzo secondario, il che significa che può ancora essere associato alla tua identità su GitLab anche dopo che hai smesso di usarlo per l’accesso.
Tre superfici, tre impostazioni diverse
| Superficie | Cosa controlla | Perché conta quando ritiri un’email |
|---|---|---|
| Email primaria | Predefinita per accesso, commit e notifiche | Cambiandola, il vecchio indirizzo viene declassato a secondario invece di essere rimosso |
| Email pubblica | L’indirizzo mostrato sul profilo pubblico | Un campo separato; può mostrare un indirizzo che non è quello di accesso |
| Email dei commit | L’indirizzo allegato ai commit che firmi | Offre un’opzione per l’email privata, ma conta anche la configurazione locale di Git |
La lezione pratica è che “rendere privato il mio profilo” e “smettere di usare questo indirizzo” non sono la stessa operazione. Ogni riga qui sopra richiede un controllo a sé.
Passo 1: decidi cosa deve mostrare il profilo pubblico
Il campo Email pubblica è un’impostazione a sé. Sceglie quale indirizzo, se presente, appare sul tuo profilo pubblico.
Il campo Email pubblica sceglie un indirizzo mostrato sul profilo pubblico ed è un’impostazione separata. Fonte
Poiché è separato, cambiare l’indirizzo di accesso primario non modifica di per sé ciò che i visitatori vedono sul tuo profilo. Controlla direttamente il campo Email pubblica e decidi se l’indirizzo lì presente è uno che sei disposto a mostrare. Se stai ritirando un indirizzo, questo è il primo posto da guardare, perché è la superficie più visibile.
Passo 2: cambia l’indirizzo primario con consapevolezza
Se l’obiettivo è smettere di accedere con un vecchio indirizzo, cambia l’email primaria. Tieni presente cosa comporta: il vecchio indirizzo primario diventa un indirizzo secondario invece di essere eliminato.
L’email primaria di GitLab è quella predefinita per accesso, commit e notifiche; cambiandola, il vecchio indirizzo primario resta come indirizzo secondario. Fonte
Quindi preparati a una seconda decisione. Dopo il cambio, rivedi gli indirizzi secondari sull’account e decidi se il vecchio debba restare allegato. Le fonti approvate qui descrivono il comportamento di declassamento ma non specificano ogni percorso di rimozione, quindi considera i passaggi esatti per rimuovere un indirizzo secondario come qualcosa da confermare nelle impostazioni del tuo account, non da dare per scontato.
Passo 3: controlla cosa espongono i tuoi commit
L’email dei commit è la superficie che più spesso si trascura, perché è legata alla cronologia del codice più che alla pagina del profilo. La selezione dell’email dei commit di GitLab include un’opzione per l’email privata.
GitLab offre “Use a private email” nella selezione dell’email dei commit; per i commit locali va considerata anche una configurazione locale di Git. Fonte
Quell’opzione copre i commit fatti tramite GitLab, ma non tutto. Una configurazione locale di Git sulla tua macchina può anch’essa determinare l’indirizzo registrato nei commit che crei localmente, quindi l’impostazione di GitLab da sola potrebbe non coprire l’intera cronologia futura. Se la privacy dei commit ti sta a cuore, controlla sia l’impostazione dell’email dei commit di GitLab sia la tua configurazione locale di Git.
Il limite dei commit storici
Questa è la parte che merita più cautela. I fatti approvati descrivono le impostazioni attuali, non una riscrittura retroattiva. Nulla nelle fonti fornite stabilisce che cambiare l’impostazione dell’email dei commit, o rendere privato il profilo, rimuova un indirizzo già registrato nei commit passati.
Tratta l’esposizione storica come una questione separata dalla configurazione attuale:
- Impostazioni attuali controllano cosa succede alle nuove attività.
- Commit passati sono stati firmati con la configurazione esistente al momento.
- Visibilità del profilo è un’impostazione di visualizzazione, non un’affermazione su cosa è memorizzato o registrato altrove.
Se il vero problema è un vecchio indirizzo nella cronologia dei commit, verifica direttamente quella superficie invece di presumere che un cambio di impostazioni sia retroattivo. Le fonti qui non documentano un meccanismo di pulizia retroattiva, quindi non pianificare su quella base.
Una checklist di verifica
Segui questi punti in ordine e annota ciò che osservi davvero nel tuo account, non ciò che ti aspetti:
- Profilo pubblico. Apri il tuo profilo come farebbe un visitatore e annota quale indirizzo, se presente, è mostrato. Poi controlla il campo Email pubblica e conferma che corrisponda alle tue intenzioni.
- Email primaria. Conferma quale indirizzo è attualmente primario e quali sono secondari. Se cambi il primario, ricontrolla l’elenco dopo e nota che il vecchio indirizzo ora figura tra gli indirizzi secondari.
- Impostazione email dei commit. Conferma quale opzione è selezionata per i commit fatti tramite GitLab.
- Configurazione locale di Git. Controlla l’email configurata su ogni macchina su cui fai commit locali, poiché può differire dall’impostazione di GitLab.
- Commit storici. Esamina i commit che hai firmato in passato e annota quale indirizzo appare. Non presumere che un cambio di impostazioni li abbia modificati.
Un’abitudine utile è ripetere i passi da 1 a 3 dopo ogni modifica, perché queste impostazioni sono indipendenti e un cambiamento in una non conferma un cambiamento in un’altra.
Dove si inserisce in una pulizia più ampia
Questa guida è volutamente ristretta: copre la separazione tra l’indirizzo del profilo pubblico, quello di accesso e quello dei commit di GitLab. Se il tuo compito più ampio è scoprire quali account sono legati a un indirizzo email, quello è un lavoro diverso. Una ricerca per username o email può far emergere corrispondenze pubbliche come indizi, ma le corrispondenze pubbliche sono indizi, non prova di proprietà, e una ricerca non è un inventario completo degli account. Per quel passo successivo, vedi la guida correlata su trovare account tramite un indirizzo email.
Se vuoi verificare dove appare un username sulle piattaforme come parte della stessa revisione, TraceSeek copre 3.000+ piattaforme e offre una prima scansione gratuita che il prodotto descrive come della durata di 20–30 secondi. Queste sono dichiarazioni del prodotto, non misurazioni indipendenti, e il risultato di una scansione va considerato un punto di partenza per la verifica, non una conferma dell’identità.
Cosa evitare
- Non presumere che nascondere il profilo pubblico rimuova un indirizzo dalla cronologia dei commit.
- Non presumere che cambiare l’email primaria elimini quella vecchia; diventa un indirizzo secondario.
- Non affidarti solo all’impostazione dell’email dei commit di GitLab se fai anche commit locali.
- Non trattare una corrispondenza pubblica tra un username e un’email come prova che appartengano alla stessa persona.
FAQ
Cambiare l’email primaria di GitLab rimuove il vecchio indirizzo?
No, in base ai fatti approvati. Il vecchio indirizzo primario viene mantenuto come indirizzo secondario, quindi resta allegato all’account e richiede una decisione separata.
Il campo Email pubblica è lo stesso della mia email di accesso?
Sono impostazioni separate. Il campo Email pubblica sceglie un indirizzo mostrato sul profilo pubblico, mentre l’email primaria è quella predefinita per accesso, commit e notifiche.
Se imposto un’email privata per i commit, i miei vecchi commit vengono aggiornati?
Le fonti fornite non stabiliscono alcun cambiamento retroattivo dei commit passati. Controlla direttamente i commit storici invece di presumere che l’impostazione sia retroattiva.
Devo cambiare qualcosa fuori da GitLab per la privacy dei commit?
Possibile. Una configurazione locale di Git influisce anche sui commit che crei localmente, quindi l’impostazione di GitLab da sola potrebbe non coprire tutto.