Guida alla versione preliminare · 0.1.0

Proteggere la cronologia da inviare

Approva e applica la protezione a un clone, esamina la cronologia committata in uscita e comprendi il motivo preciso di un blocco.

Il riferimento API è in inglese.

Applica la protezione al clone previsto

La protezione dei push usa un hook Git locale installato esplicitamente. Una scansione fallita o un gate configurato non lo installa. Parti dal profilo connesso, dal repository esatto autorizzato e dagli scanner pronti.

1. Esegui CodeSecurity: Protect Pushes… in VS Code. La palette chiede il repository; il menu repository di Source Control usa il clone selezionato.
2. Controllane l’identità. Risolvi selezioni obsolete o ambigue prima di procedere.
3. Richiedi accesso al repository, poi approva quella generazione esatta dell’editor nel browser del proprietario associato. L’appartenenza IDE ordinaria non concede questo permesso.
4. Scegli l’impostazione richiesta On e usa esplicitamente Apply in VS Code.
5. Leggi lo stato dell’host e risolvi conflitti di hook prima di affidarti alla protezione.

L’impostazione web registra lo stato richiesto. Change pending · Apply in VS Code significa che l’host non lo ha applicato. Vale anche per Off: un hook On applicato può continuare a bloccare fino all’applicazione del cambiamento. On · last verified e Off · last applied descrivono l’ultima osservazione.

L’hook invoca un helper distribuito separatamente e può operare con editor chiuso se il backend richiesto è disponibile. L’installazione conserva altri hook e la configurazione locale del loro percorso; rifiuta conflitti non componibili in sicurezza. Non cambia impostazioni Git globali o remoti.

Esamina i commit in uscita prima del push

Esegui CodeSecurity: Check Outgoing Commits… dalla palette o dal menu Source Control del repository previsto. Seleziona destinazione configurata, branch o tag locale e ref remota esplicita. Esamina l’ambito prima dell’invio di snapshot e scansioni. Il comando controlla; non esegue push.

Il controllo lega repository canonico, coppie di ref e oggetti in uscita, alberi immutabili, copertura autorizzata, policy corrente ed evidenze. Una scansione di workspace, file, cartella o l’ultima selezionata nella web UI non sostituisce quella cronologia committata.

Un segreto introdotto in un commit in uscita e rimosso nel successivo viaggia comunque nel primo. Una punta pulita non lo cancella. Esamina l’albero storico fallito anziché ripetere la scansione solo dei file attuali.

Ogni repository ha un esito indipendente. Contenuto immutabile invariato può riusare evidenze applicabili, ma cambi a ref, policy, decisioni o identità di scanner e dati possono invalidare l’approvazione. Consultare il catalogo non installa nuovi dati. La disponibilità corrente determina ancora se l’evidenza è utilizzabile.

Leggi l’esito del piano esatto

Un push con sorgenti richiede evidenze completate, applicabili e approvate. Verifica mancante, fallita, obsoleta, parziale, annullata o indisponibile lo blocca. Disabilitare il gate non produce approvazione; cambiare decisioni non colma lacune di copertura.

Un piano di sola eliminazione o senza effetti non ha alberi in uscita da analizzare. Può completarsi senza scanner, ma approvazione e policy corrente valgono comunque. Leggi il piano effettivo: una lista vuota non prova l’assenza di alberi.

Annullare ferma il job corrente annullabile e conserva i risultati precedenti. Un controllo annullato conservato può offrire Start new check, mostrando ambito e identità precedenti di job e scansioni. Accettarlo ricontrolla lo stato e può riusare evidenze complete applicabili. Non riclassifica il controllo annullato come superato.

Diagnostica un push bloccato

Le notifiche normali di Git o GitLens possono suggerire genericamente un pull. Apri Show Command Output in VS Code o Open Output Channel in GitLens e leggi l’esito effettivo. Se indica Lomo blocked this push, torna alla protezione e al controllo in uscita del clone.

Usa Review blocking findings dopo una scansione in uscita completata ma fallita. Apre l’esatta scansione dell’albero committato; scegli quella prevista se più alberi sono falliti. L’evidenza storica non apre il file corrente come se fosse l’albero controllato. Open protection settings apre il record del repository senza modificare gate o permessi.

Un branch non pubblicato, un remoto non configurato o Nothing to push possono fermare il client prima dell’hook. Non stabiliscono una decisione di autorizzazione CodeSecurity. Conferma branch e destinazione Git oltre all’esito di sicurezza.

Riconosci i limiti di copertura

La copertura riguarda file regolari negli alberi dei nuovi commit in uscita. Messaggi di commit, tag e altri metadati non sono input file dello scanner. Symlink non supportati, submodule, repository shallow, archivi alternativi di oggetti e copertura non verificabile sono rifiutati.

Una ref remota esistente richiede il vecchio commit disponibile localmente. Un branch nuovo non ha una base vecchia: tutta la cronologia raggiungibile dalla punta conta per il limite anche se un altro branch remoto ne contiene parte. Il controllo non scarica oggetti mancanti o tronca silenziosamente la cronologia.

Un rifiuto per limite non approva alcun push. Riduci le ref se risolve quel limite, oppure concorda un percorso di revisione e applicazione approvato separatamente per cronologie o alberi non supportati. Una scansione più piccola del workspace non fornisce l’evidenza mancante.

Disattiva o rimuovi la protezione

Impostare Off richiede l’avviso e l’applicazione esplicita sull’host. Annullare lascia invariata l’impostazione. Dopo Off, l’helper non legge sorgenti, non richiede API online e non impone limiti di sorgenti e ref esclusivi di On. Registrazione e configurazione dell’hook rimangono per una riattivazione esplicita.

Rimuovere è un’altra azione. Nel profilo proprietario esatto, scegli Protect Pushes… > Remove push protection from this clone… e conferma il repository. Rimuove solo hook Lomo invariato, registrazione e concessioni e legami specifici. Conserva progetti, scansioni, rilievi, snapshot, associazione generale, remoti e hook di altri strumenti.

Un progetto ancora usato dalla protezione o dalla sua fonte di snapshot Git non può essere eliminato, anche con Off. Rimuovi prima la registrazione se vuoi poi eliminare il progetto.

Se la rimozione locale riesce ma la pulizia server è indisponibile, riprova dallo stesso profilo quando torna il servizio. Hook modificati o sconosciuti sono conservati. Dopo revoca e nuova iscrizione dell’editor, richiedi l’approvazione della nuova generazione e applica ancora; non eredita la vecchia concessione.

Prova senza pubblicare sorgenti

Per una verifica manuale deliberata, usa un repository sacrificabile e un remoto bare locale esatto. Usa rilievi sintetici e verifica le ref prima e dopo normali push Git. Un blocco deve lasciarle invariate; un push consentito deve cambiare solo quelle previste. Includi una cronologia precedente problematica seguita da una punta pulita, così un controllo della sola punta non sembri sufficiente.

Il proprietario può aggirare l’hook o usare un altro clone. Mantieni controlli remoti adeguati dove l’applicazione deve essere inevitabile. Una verifica manuale riuscita copre i casi esercitati, non tutte le piattaforme, ref o vie di recupero.

Consulta decisioni del gate, revisione dei rilievi e API di protezione Git per i controlli correlati.