Trova un commit perso con reflog

• Leggi il reflog come la registrazione di questo repository di dove sono stati HEAD e i rami.
• Controlla il contenuto di un commit candidato prima di salvarlo.
• Crea un ramo nel commit misurato senza estrarlo.
• Di' ciò che il reflog non può riportare indietro: lavoro non impegnato e voci scadute.

Sei su private/lost-signup, un ramo del risultato M della lezione 18. Hai eseguito il commit di una nota, "docs: keep the signup recovery note", che ha aggiunto docs/signup-recovery.md, quindi hai eseguito un hard reset con un commit precedente. La nota è scomparsa dal ramo, dal grafico e dai tuoi file. Non hai ancora un ramo di salvataggio e non hai cambiato nient'altro.

Tutto è locale e nel piano gratuito (GitTree ti chiede di accedere): nessun account di hosting, nessun provider, niente Internet. Ogni identità è fittizia (esempio.com). Non eseguire mai questa lezione in un progetto reale. L'hard reset nella preparazione è una prova in copia usa e getta.

Apporta le modifiche in GitTree o con i comandi Git nativi, non entrambi nella stessa copia. Leggere il risultato è sempre sicuro. Le etichette dei menu provengono dalle stringhe proprie di GitTree 2.0 e i comandi nativi sono stati eseguiti con Git 2.43 in copie usa e getta. I passaggi GitTree non sono stati eseguiti su macOS, Windows o Linux.

Il reflog è un diario locale dei movimenti degli arbitri. HEAD ne ha uno, così come ogni ramo. Registra "commit", "checkout", "reset" e simili, con il commit su cui è arrivato ciascuno. Un altro clone non ha il tuo diario. Un commit in cui non possono ancora esistere nomi di rami e il reflog è il modo in cui lo trovi.

Selettori come HEAD@{1} contano le voci a ritroso da adesso, quindi cambiano con ogni operazione successiva. Leggi l'azione, l'ora, l'ID e il file di un candidato prima di utilizzarlo. Non memorizzare un offset come ricetta.

Il reflog trova i commit che sono stati salvati. Non è possibile trovare una modifica che non sia mai stata confermata, come ha mostrato la lezione 27. Le voci scadono: per impostazione predefinita Git conserva le voci per i commit che nessun ramo raggiunge per circa trenta giorni e un repository può modificarlo. Non eseguire comandi di pulizia o di scadenza durante il ripristino.

La creazione di un ramo al commit aggiunge un riferimento e nient'altro. Il ramo corrente, l'indice e i tuoi file rimangono dove sono.

Inizia da una copia ordinaria separata del risultato M della lezione 18 e lascia intatto il tuo originale. Crea il ramo, salva DOC_LOST, esegui il commit e ripristina un commit. Questa preparazione distruttiva è solo per una copia usa e getta.

Risparmia solo nella fase denominata di seguito. Questi sono corpi UTF-8/LF completi con un ritorno a capo finale; non incollare mai le recinzioni Markdown. I file eseguibili non modificati ereditano l'input denominato. Le versioni in varianti separate non devono sovrascrivere l'originale.

docs/signup-recovery.md — DOC_LOST

# Recovered signup work

Keep a branch name before leaving useful experimental work.

Apri la tavolozza con Comando+Maiusc+P (Ctrl+Maiusc+P su Ubuntu).

1. Costruisci la prova come mostra la sezione successiva e annota l'oggetto del commit perduto.
2. Apri la tavolozza ed esegui View Reflog…. La finestra di dialogo "Reflog" si apre con Reflog of impostato su HEAD; le voci vengono elencate per prime.
3. Leggi le voci più importanti. Il più recente dice "reimposta" e quello sotto dice "impegna" con oggetto "documenti: mantieni la nota di ripristino della registrazione". Utilizza Show Older Entries se l'elenco è lungo. Non dare per scontato che la seconda riga sia sempre quella giusta.
4. Seleziona la voce di commit. La finestra di dialogo mostra Show in Graph e New branch name. Show in Graph può inserire solo un commit raggiunto da un ramo, quindi per questo commit perso chiude la finestra di dialogo e il grafico rimane su M: riapre il reflog per il passaggio successivo. Leggi il file del commit dopo averlo ripristinato.
5. Tornando alla finestra di dialogo, seleziona la stessa voce, digita rescue/signup in New branch name e scegli Restore as Branch. L'avviso dice "Creato salvataggio/registrazione del ramo. Annulla lo rimuove di nuovo".
6. Controlla il risultato: rescue/signup punti al commit perso, il ramo corrente è ancora private/lost-signup su M e i tuoi file sono invariati. Seleziona il commit ripristinato e apri il suo file docs/signup-recovery.md: è DOC_LOST.
7. Lasciare il ramo di salvataggio sul posto. Non eseguire alcuna pulizia per riordinare il grafico.

Per ogni commit ordinario nel corso: Summary è l'oggetto dichiarato, Description è vuoto e le opzioni Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit e Allow Empty Commit rimangono disattivate.

Solo in una copia separata e pulita del risultato della lezione 18:

git switch --create private/lost-signup

Salva DOC_LOST come docs/signup-recovery.md, quindi:

git add -- docs/signup-recovery.md
git commit --quiet -m "docs: keep the signup recovery note"
git reset --hard HEAD~1
git reflog show --format=%gs -2 HEAD

reset: moving to HEAD~1
commit: docs: keep the signup recovery note

Elenca i candidati con i loro documenti d'identità e controlla quello che ritieni sia perso:

git reflog show --format='%H %gs' HEAD
git show "<lost-sha>:docs/signup-recovery.md"

Sostituisci <lost-sha> con l'ID nella riga "commit: docs: keep the signup recovery note". In questo esempio immediato HEAD@{1} è lo stesso commit, ma quell'offset non è una regola. Crea il ramo di salvataggio senza verificarlo:

git branch rescue/signup "<lost-sha>"
git show rescue/signup:docs/signup-recovery.md
git symbolic-ref --short HEAD
git status --short

Il file è DOC_LOST, il ramo stampato è private/lost-signup e lo stato è vuoto. I tuoi file non mostrano la nota, perché HEAD è rimasto su M. Nessun comando di scadenza o pulizia ne fa parte.

Where you end: rescue/signup punta al commit perduto e il suo file è DOC_LOST. Il ramo corrente, l'indice e i tuoi file sono esattamente come erano dopo il ripristino e non è stato inviato nulla.

• Utilizzo di HEAD@{1} come ricetta fissa invece di leggere la voce.
• Reimpostare o eseguire nuovamente il check-out prima di salvare un ramo, che aggiunge più voci e seppellisce quella desiderata.
• Mi aspetto che il reflog contenga una modifica che non è mai stata confermata.
• Esecuzione di comandi di pulizia mentre cerchi qualcosa.

Se il commit non è nell'elenco, potresti guardare il riferimento sbagliato: cambia Reflog of tra HEAD e il ramo e usa Show Older Entries. Se è veramente scomparso, è scaduto o non è mai stato impegnato. Nell'app, l'avviso dopo Restore as Branch dice che Annulla rimuove nuovamente il ramo.

Rispondi a ciascuna domanda, quindi leggi il motivo. Le domande contrassegnate come "Obbligatorio" contano ai fini del completamento della lezione.

1. Domanda 1 di 6

   Domanda 1 di 6

   Cos'è il reflogging?

   Scegli una risposta.

   Un registro condiviso che ogni clone e il server mantengono al passo.

   Un backup dei tuoi file.

   Un record locale di dove hanno puntato HEAD e ciascun ramo.

   La stessa cosa del grafico di commit.

   Controlla la risposta
2. Domanda 2 di 6

   Domanda 2 di 6

   Quali di queste sono vere per il reflog?

   Scegli ogni risposta applicabile.

   Memorizza le modifiche che non hai mai apportato.

   HEAD e ogni ramo hanno il proprio.

   Le vecchie voci scadono.

   Un altro clone del progetto non ha le tue voci.

   Controlla la risposta
3. Domanda 3 di 6

   Domanda 3 di 6Obbligatorio

   Hai trovato il commit perduto nel reflog e hai utilizzato Ripristina come ramo con il nome rescue/signup. Cosa vedi?

   Scegli una risposta.

   rescue/signup punti al commit perso e sei ancora su private/lost-signup su M con i tuoi file invariati.

   Ora sei su rescue/signup e la nota è di nuovo nei tuoi file.

   private/lost-signup va avanti al commit perduto.

   La voce di reflog viene eliminata.

   Controlla la risposta
4. Domanda 4 di 6

   Domanda 4 di 6

   Cambia l'input: non hai mai confermato la nota e quindi hai eseguito l'hard reset. Il reflog può riportarlo indietro?

   Scegli una risposta.

   Sì, tramite Mostra voci precedenti.

   Sì, con HEAD@{1}.

   No. Il reflog punta ai commit e questo contenuto non è mai stato presente in uno di essi.

   Sì, spostando Reflog su branch.

   Controlla la risposta
5. Domanda 5 di 6

   Domanda 5 di 6Obbligatorio

   Hai eseguito ancora qualche operazione, quindi hai eseguito git branch rescue HEAD@{1} e il file non è quello che volevi. Quello che è successo?

   Scegli una risposta.

   HEAD@{1} è sempre il commit corretto dopo un ripristino.

   Il reflog è corrotto.

   Il commit perduto è stato cancellato dal nuovo ramo.

   HEAD@{1} conta all'indietro da adesso, quindi ogni nuova operazione cambia il suo nome. Leggi l'elenco e utilizza l'ID del commit perduto.

   Controlla la risposta
6. Domanda 6 di 6

   Domanda 6 di 6Obbligatorio

   Dopo aver creato il ramo di salvataggio, quali riletture mostrano che ha funzionato come dice la lezione?

   Scegli ogni risposta applicabile.

   docs/signup-recovery.md ora esiste nei tuoi file.

   git show rescue/signup:docs/signup-recovery.md stampa la nota recuperata, iniziando con "# Recovered signup work".

   git status --short non stampa nulla.

   git symbolic-ref --short HEAD stampa private/lost-signup.

   Controlla la risposta

Riporta le due righe di reflog più recenti, l'ID del commit perso, la prima riga del file recuperato e il ramo su cui si trova il tuo checkout. Quindi dì cosa mostrerebbe il reflog per una modifica che non hai mai eseguito.

• Il reflog è un diario locale dei movimenti degli arbitri.
• Controllare il candidato, quindi diramarlo.
• Trova i commit, non le modifiche non salvate.

• Reimpostazione: morbido, misto e difficile (lezione 27)
• Leggi la cronologia senza muovere la TESTA (lezione 8)
• Scarica GitTree

Reflog — سجل المراجع; ramo di salvataggio: فرع حفظ; selettore — محدِّد.