Recupero e il reflog

Git raramente perde qualcosa. La parte difficile è ritrovarlo.

Reflog

Ogni movimento di HEAD — e di ciascun branch — con la causa che l'ha prodotto: checkout, reset, rebase, amend, un fetch forzato. Da qualunque voce passata puoi farne il checkout, crearci un branch o fare un hard reset su di essa.

Questo è il pulsante "ho appena resettato il branch sbagliato".

Snapshot del lavoro in corso

Il lavoro non committato è l'unica cosa che il reflog non può salvare, quindi Gitcito ne fa uno snapshot: l'intero albero di lavoro — file modificati, in stage e non tracciati — committato tramite un indice usa e getta e fissato sotto refs/gitcito/wip. Né il tuo indice reale né il tuo elenco degli stash vengono toccati.

Tre cose ne prendono uno:

La guardia è quella che conta: il momento in cui di solito il lavoro va perso per sempre è il secondo dopo uno scarto che non intendevi fare. Con la guardia attiva, quello stato è uno snapshot — apri l'elenco, fai clic su ripristina, tira il fiato.

Seleziona uno snapshot per vedere i file che ha catturato, visualizzare in anteprima la modifica di qualsiasi file e ripristinare un singolo file o l'intero albero. Il ripristino copia i file dallo snapshot sopra le copie correnti — prima viene preso uno snapshot di guardia, quindi anche un ripristino è annullabile.

Limiti da conoscere. Un tick del timer o della guardia che non trova nulla di nuovo non registra nulla. Il ripristino sovrascrive e ricrea i file, ma non elimina mai un file creato dopo lo snapshot. I file ignorati non vengono catturati. Gli snapshot sono ref nascosti locali: mai pushati, al sicuro da git gc, si conservano i 50 più recenti.

Bisect guidato

Segna i commit come buoni e cattivi, guarda l'intervallo restringersi, atterra sul primo commit cattivo. Gitcito tiene il conto di quanti passi mancano, così sai se sei a due domande dalla risposta o a dieci.

Lascia decidere a un comando

Una volta seminato l'intervallo, Lascia decidere a un comando affida l'intera ricerca a git bisect run. Git fa il checkout di ogni candidato, esegue il tuo comando e legge il suo codice di uscita:

Una suite di test parla già quella lingua, ed è per questo che npm test è di solito tutta la risposta. Gitcito propone gli script di questo progetto come riempimenti in un clic, mostra l'output in tempo reale mentre gira e atterra sul primo commit cattivo senza che tu risponda a una sola domanda.

A cosa fare attenzione. Il comando viene eseguito su ogni commit che git prova, quindi un comando che fa deploy, pubblica o scrive fuori dal repository lo farà parecchie volte. Limitalo a qualcosa che si limita a leggere e riferire. Stop interrompe l'esecuzione e lascia aperta la sessione, così puoi proseguire segnando a mano; Interrompi chiude del tutto il bisect.

Un comando che fallisce per un motivo non correlato — una dipendenza mancante in quel punto della storia, per esempio — segna come cattivo un commit buono e manda la ricerca nel posto sbagliato. Uscire con 125 da uno script wrapper è la via d'uscita che git offre.

Un file di lock rimasto indietro

Git crea un file .lock accanto a ciò che sta per scrivere e lo rimuove quando la scrittura va a buon fine. Un processo che muore tenendolo — un editor che si pianta, un terminale chiuso durante git commit, un fetch ucciso mentre potava i riferimenti remoti — lascia lì il lock, e da quel momento ogni scrittura fallisce con la stessa riga:

error: could not delete references: cannot lock ref 'refs/remotes/origin/x':
Unable to create '…/refs/remotes/origin/x.lock': File exists.

Il repository non è danneggiato. C'è semplicemente un file di mezzo.

Gitcito prima riprova qualche volta, perché un lock tenuto da un git in corso di solito si libera in millisecondi. Quando non succede, l'errore apre una finestra invece di un muro di testo: tutti i lock ancora su disco, quanto è vecchio ciascuno, e un pulsante che li rimuove e riesegue l'azione fallita.

L'età è tutto l'argomento. Un lock più giovane di 30 secondi si presume di un git ancora al lavoro, e Gitcito si rifiuta di cancellarlo: offre invece di aspettare e riprovare. Quelli più vecchi vengono proposti per la rimozione, dal più vecchio in giù, e la finestra dice chiaramente cosa controllare prima di accettare: che nessun editor, terminale o altro client Git stia lavorando adesso in questo repository. Togliere un lock sotto una scrittura viva è il modo in cui un indice si lacera.

La scansione copre la directory git del repository e la sua directory comune, quindi trova anche i lock di un worktree collegato. I sottomoduli vengono saltati: appartengono a un altro repository e si puliscono aprendolo.

Annulla / ripeti

Quasi tutte le operazioni infilano una voce in una pila di annullamento, quindi ⌘Z inverte l'ultima dove git lo consente.

Vedi anche: Cos'è cambiato da · Stash