Close

Git Reflog

Questa pagina fornisce una discussione dettagliata del comando git reflog. Git tiene traccia degli aggiornamenti alla punta dei branch utilizzando un meccanismo chiamato log di riferimento o "reflog. " Molti comandi Git accettano un parametro per specificare un riferimento o un "ref", che è un puntatore a un commit. Gli esempi più comuni includono:

  • Git checkout
  • git reset
  • git merge

Reflog tiene traccia di quando i riferimenti di Git sono stati aggiornati nel repository locale. Oltre ai reflog delle punte dei branch, viene mantenuto un reflog speciale per lo stash Git. I reflog sono archiviati nelle directory della directory .git del repository locale. Le directory git reflog possono essere trovate all'indirizzo .git/logs/refs/heads/., .git/logs/HEAD, e anche .git/logs/refs/stash se git stash è stato utilizzato nel repository.

Abbiamo parlato di git reflog in generale nella pagina della riscrittura della cronologia. Questo documento tratterà: opzioni di configurazione estese di git reflog, casi d'uso comuni e insidie di git reflog, come annullare le modifiche con git reflog e altro ancora.


Utilizzo di base


Il caso d'uso più semplice di Reflog è il richiamo:

git reflog

Questa è essenzialmente una scorciatoia che equivale a:

git reflog show HEAD

Verrà emesso il reflog HEAD. Dovresti vedere un output simile a:

eff544f HEAD@{0}: commit: migrate existing content
bf871fd HEAD@{1}: commit: Add Git Reflog outline
9a4491f HEAD@{2}: checkout: moving from main to git_reflog
9a4491f HEAD@{3}: checkout: moving from Git_Config to main
39b159a HEAD@{4}: commit: expand on git context 
9b3aa71 HEAD@{5}: commit: more color clarification
f34388b HEAD@{6}: commit: expand on color support 
9962aed HEAD@{7}: commit: a git editor -> the Git editor
Logo Git
materiale correlato

Scheda di riferimento rapido di Git

Logo di Bitbucket
Scopri la soluzione

Impara a utilizzare Git con Bitbucket Cloud

Visita la pagina della riscrittura della cronologia per un altro esempio di accesso reflog comune.

Riferimenti Reflog

DevOps riguarda tutte le fasi del ciclo di vita dello sviluppo e delle operazioni. Dalla pianificazione e compilazione al monitoraggio e all'iterazione, DevOps riunisce le competenze, i processi e gli strumenti di ogni aspetto di un'organizzazione di progettazione e IT.

Le metodologie Agile aiutano i team a pianificare e produrre suddividendo il lavoro in task e milestone gestibili. Agile fa affidamento su sprint, backlog, epic e story per assegnare il lavoro ai membri del team qualificati, adattare le timeline quando necessario e fornire prodotti e servizi di qualità ai clienti. Scopri di più su Agile.

Continuous integration e delivery: la pietra angolare delle pratiche DevOps basata sull'automazione del merge e della distribuzione del codice. Secondo i metodi di sviluppo tradizionali, gli ingegneri devono aggiornare manualmente le modifiche nella codebase, con ulteriori controlli manuali per garantire che un codice di qualità sia pronto per essere rilasciato nell'ambiente di produzione. Le distribuzioni sono pianificate a intervalli di settimane o mesi per eliminare la probabilità di bug o imprevisti. Le pratiche DevOps consentono di accorciare questi intervalli di tempo automatizzando le funzioni di merge, test e distribuzione. I team ad alte prestazioni utilizzano CI/CD per cambiare la frequenza delle distribuzioni da ogni paio di mesi a più volte al giorno. Scopri di più su CI/CD.

I repository e i flussi di lavoro Git abilitano le funzionalità di automazione e controllo delle versioni, fondamentali per le pratiche DevOps. Dal momento che Git è distribuito, le operazioni come commit, blame, diff, merg e log avvengono più velocemente. Git supporta anche la creazione di branch, il merge e la riscrittura della cronologia dei repository, il che porta a flussi di lavoro e strumenti potenti. Scopri di più su Git.

La gestione dei servizi IT è il processo utilizzato dai team IT per gestire la produzione end-to-end dei servizi IT ai clienti. Questo comprende tutti i processi e le attività di progettazione, creazione, rilascio e assistenza dei servizi IT. Il concetto centrale di ITSM è la convinzione che l'IT debba essere rilasciato come servizio, andando quindi oltre il supporto IT di base. I team ITSM supervisionano tutte le tecnologie sul posto di lavoro: dai computer portatili ai server fino alle applicazioni software business critical. Leggi ulteriori informazioni su ITSM.

I team di gestione degli imprevisti rispondono agli eventi non pianificati o alle interruzioni del servizio e ripristinano il servizio allo stato operativo. Nel modello "You Build It, You Run It", gli sviluppatori collaborano con gli addetti alle operazioni per ridurre la probabilità che si verifichi un imprevisto e il tempo medio di ripristino in caso di imprevisto. Scopri di più sulla gestione degli imprevisti.

Per impostazione predefinita, git reflog emetterà il reflog del riferimento HEAD. HEAD è un riferimento simbolico al branch attualmente attivo. I reflog sono disponibili anche per altri riferimenti. La sintassi per accedere a un git ref è nome@{qualifier}. Oltre ai riferimenti HEAD, è possibile fare riferimento anche ad altri branch, tag, remoti e allo stash Git.

Puoi ottenere un reflog completo di tutti i riferimenti eseguendo:

 git reflog show --all 

Per vedere il reflog per un branch specifico, passa il nome del branch a git reflog show

In Bitbucket, viene visualizzata la pagina Create a new repository (Crea un nuovo repository). Leggi con attenzione il contenuto della finestra di dialogo. Puoi modificare in un secondo momento tutte le informazioni che inserisci in questa pagina, a eccezione del campo Repository type (Tipo di repository).

git reflog show otherbranch



9a4491f otherbranch@{0}: commit: seperate articles into branch PRs
35aee4a otherbranch{1}: commit (initial): initial commit add git-init and setting-up-a-repo docs

L'esecuzione di questo esempio mostrerà un reflog per il branch otherbranch. L'esempio seguente presuppone che tu abbia precedentemente nascosto alcune modifiche utilizzando il comando git stash.

git reflog stash

0d44de3 stash@{0}: WIP on git_reflog: c492574 flesh out intro

Verrà generato un reflog per lo stash Git. I puntatori di riferimento restituiti possono essere passati ad altri comandi Git:

git diff stash@{0} otherbranch@{0}

Una volta eseguito, questo codice di esempio mostrerà l'output Git diff confrontando le modifiche di stash@ {0} con il riferimento otherbranch@ {0}.

Reflog temporizzati

A ogni voce di reflog è associato un timestamp. Questi timestamp possono essere utilizzati come token qualificatore della sintassi del puntatore di riferimento Git. Ciò consente di filtrare i reflog Git in base al tempo. Di seguito sono riportati alcuni esempi di qualificatori temporali disponibili:

  • 1.minute.ago
  • 1.hour.ago
  • 1.day.ago
  • Ieri
  • 1.week.ago
  • 1.month.ago
  • 1.year.ago
  • 17/05/2011. 09:00:00

I qualificatori temporali possono essere combinati (ad es. 1.day.2.hours.ago), Inoltre sono accettate forme plurali (ad es. 5.minutes.ago).

I riferimenti ai qualificatori temporali possono essere passati ad altri comandi git.

 git diff main@{0} main@{1.day.ago} 

Questo esempio differenzia l'attuale branch principale da quello principale di 1 giorno fa. Questo esempio è molto utile se vuoi conoscere i cambiamenti che sono avvenuti in un periodo di tempo.

Sottocomandi e opzioni di configurazione


git reflog accetta alcuni argomenti aggiuntivi che sono considerati sottocomandi.

Mostra: git reflog show

show è passato implicitamente per impostazione predefinita. Ad esempio, il comando:

git reflog main@{0} 

è equivalente al comando:

git reflog show main@{0} 

Inoltre, git reflog show è un alias per git log -g —abbrev-commit —pretty=oneline. Esecuzione di git reflog show mostrerà il registro del passato.

Scadenza - git reflog expire

Il sottocomando expire pulisce le voci di reflog vecchie o irraggiungibili. Il sottocomando expire potrebbe causare la perdita di dati. Questo sottocomando non è in genere utilizzato dagli utenti finali, ma viene utilizzato internamente da git. Passare un'opzione -n o —dry-run a git reflog expire eseguirà un "dry run" che mostrerà quali voci di reflog sono contrassegnate per essere eliminate, ma non le eliminerà effettivamente.

Per impostazione predefinita, la data di scadenza del reflog è impostata su 90 giorni. È possibile specificare una data di scadenza passando l'argomento della riga di comando —expire=time a git reflog expire o impostando il nome di configurazione git gc.reflogExpire.

Elimina: git reflog delete

Il sottocomando delete si spiega da sé e eliminerà una voce di reflog passata. Come per expire, delete potrebbe causare la perdita di dati e non viene comunemente richiamato dagli utenti finali.

Recupero dei commit persi


Git non perde mai davvero nulla, anche quando esegue operazioni di riscrittura della cronologia come rebase o modifica dei commit. Per il prossimo esempio supponiamo di aver apportato alcune nuove modifiche al nostro repository. Il nostro git log —pretty=oneline ha il seguente aspetto:

338fbcb41de10f7f2e54095f5649426cb4bf2458 extended content
1e63ceab309da94256db8fb1f35b1678fb74abd4 bunch of content
c49257493a95185997c87e0bc3a9481715270086 flesh out intro
eff544f986d270d7f97c77618314a06f024c7916 migrate existing content
bf871fd762d8ef2e146d7f0226e81a92f91975ad Add Git Reflog outline
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docs

Quindi apportiamo le modifiche ed eseguiamo quanto segue:

#make changes to HEAD
git commit -am "some WIP changes"

Con l'aggiunta del nuovo commit. Il registro ora ha il seguente aspetto:

$ git clone

https://emmap1@bitbucket.org/emmap1/bitbucketstationlocations.git 

Cloning into 'bitbucketspacestation'...

fatal: could not read

Password for 'https://emmap1@bitbucket.org': No such file or directory

Se ricevi questo errore, inserisci quanto segue nella riga di comando:

37656e19d4e4f1a9b419f57850c8f1974f871b07 some WIP changes
338fbcb41de10f7f2e54095f5649426cb4bf2458 extended content
1e63ceab309da94256db8fb1f35b1678fb74abd4 bunch of content
c49257493a95185997c87e0bc3a9481715270086 flesh out intro
eff544f986d270d7f97c77618314a06f024c7916 migrate existing content
bf871fd762d8ef2e146d7f0226e81a92f91975ad Add Git Reflog outline
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docs

A questo punto eseguiamo un rebase interattivo sul branch principale eseguendo...

git rebase -i origin/main

Durante il rebase contrassegniamo i commit per squash con il sottocomando s di rebase. Durante il rebase, aggiungiamo alcuni commit ai commit più recenti di "alcune modifiche WIP".

Poiché abbiamo eliminato i commit, l'output del log di git ora ha il seguente aspetto:

40dhsoi37656e19d4e4f1a9b419f57850ch87dah987698hs some WIP changes
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docs

Se esaminiamo git log a questo punto sembra che non abbiamo più i commit contrassegnati per lo squashing. E se volessimo operare su uno dei commit sottoposti a squash? Magari per rimuovere le modifiche dalla cronologia? Questa è un'opportunità per sfruttare reflog.

git reflog
37656e1 HEAD@{0}: rebase -i (finish): returning to refs/heads/git_reflog
37656e1 HEAD@{1}: rebase -i (start): checkout origin/main
37656e1 HEAD@{2}: commit: some WIP changes

Possiamo vedere che ci sono voci di reflog per l'inizio e la fine del rebase e prima di queste c'è il nostro commit per le "modifiche WIP". Possiamo passare il ref reflog a git reset e resettare a un commit precedente al rebase.

git reset HEAD@{2}

L'esecuzione di questo comando di ripristino sposterà HEAD nel commit in cui sono state aggiunte "alcune modifiche WIP", essenzialmente ripristinando gli altri commit sottoposti a squash.

Riepilogo


In questo tutorial abbiamo discusso del comando git reflog. Alcuni punti chiave trattati sono stati:

  • Come visualizzare i reflog per branch specifici
  • Come annullare un rebase git usando reflog
  • Come specificare e visualizzare i reflog in base al tempo

We briefly mentioned that git reflog can be used with other git commands like git checkout, git reset, and git merge. Learn more at their respective pages. For additional discussion on refs and the reflog, learn more here.


Condividi l'articolo
Argomento successivo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Le persone collaborano utilizzando una parete piena di strumenti

Blog di Bitbucket

Illustrazione su Devops

Percorso di apprendimento DevOps

Funzione Demo Den per demo con esperti Atlassian

Come Bitbucket Cloud funziona con Atlassian Open DevOps

Iscriviti alla nostra newsletter DevOps

Thank you for signing up