Informazioni sulla semplificazione della cronologia di Git

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

La semplificazione della cronologia Git può essere una bestia confusa. 99% del tempo che non si saprà neanche esiste, ma occasionalmente salterà fuori dagli angoli scuri di Git e morderti. In questo articolo si esaminerà la semplificazione della cronologia e come può causare confusione quando si esamina la cronologia dei file.

Si inizierà con uno scenario comune:

1. Si esegue il push di una modifica in un file e quindi si unisci la modifica in main.
2. Alcuni colleghi unisce anche i rami a main.
3. Si torna indietro più tardi e si nota che le modifiche sono mancanti.
4. Cercando il colpevole, si va a guardare la cronologia dei file e notare... le modifiche non sono elencate!?

La cronologia del commit Git è un albero. In alcuni casi, la cronologia cronologica non corrisponde alla cronologia effettiva dell'albero dei file. Questa situazione si verifica più spesso quando un commit di merge ripristina lo stato originale di un file. In tal caso, la visualizzazione cronologia predefinita non mostrerà tutte le modifiche, perché tecnicamente il file non è stato modificato. In questo scenario Git si rende conto che può semplificare la cronologia e le "modifiche" che probabilmente si stanno cercando vengono rimosse dal log.

A meno che tu non lo abbia fatto prima, potresti diventare frustrato, chiedendoti dove sono andati i miei cambiamenti?

Semplificazione della cronologia: attivato per impostazione predefinita

Per impostazione predefinita, l'esecuzione del comando di log in un file git log file.txt semplifica automaticamente la cronologia, probabilmente nascondendo alcuni commit dal relativo output. Per altre informazioni, vedere la pagina git log man.

Ciò che aggiunge alla confusione è che la semplificazione della cronologia non si verifica se si esegue git logsemplicemente , perché si stanno esaminando tutte le modifiche non c'è nulla da semplificare.

Per disattivare la semplificazione della cronologia, è necessario usare l'opzione --full-historydella riga di comando .

Un esempio di semplificazione della storia

Per comprendere meglio il funzionamento della semplificazione, creiamo il nostro esempio di semplificazione della storia. Prima di tutto, si esaminerà un diagramma della cronologia che verrà creato:

Come si può notare, si procederà a:

1. Creare un file .
2. Aggiungere una riga a tale file in un ramo (animali).
3. Aggiungere una riga diversa a tale file in un altro ramo (frutto).
4. Unisci gli animali diramazione in main.
5. Unire il frutto del ramo in main e scegliere l'intera copia del file dal ramo fruit.
6. Controllare la cronologia del file.

Git semplifica la cronologia. Il passaggio 5 è la chiave qui. Abbiamo ignorato tutte le modifiche dal ramo animale . Git noterà che il file essenzialmente non è cambiato tra il passaggio 1 e il passaggio 5 e quindi mostrerà solo due voci di cronologia.

Prima di tutto creiamo il file e lo aggiungiamo al repository:

> cd sample
> git init
> echo "some content" > test.txt
> git add test.txt
> git commit -m "Initial commit"

Ora decidiamo di aggiungere il testo "asini" al file in un ramo animale:

> git checkout -b animals
> echo "donkeys" >> test.txt
> git commit -am "We have added an animal"

Durante l'esperimento, decidiamo forse di voler usare frutta nel file, quindi creiamo un ramo diverso e accodiamo il testo "banana" alla fine del file:

> git checkout main -b fruit
> echo "bananas" >> test.txt
> git commit -am "We have added a fruit"

Sentirsi soddisfatti dei nostri cambiamenti, decidiamo di unire il nostro ramo animale di nuovo in main:

> git checkout main
> git merge animals

Si esaminerà ora il log per il test.txt file:

> git log test.txt
    
    commit 6b33d99b996c430a60c9552b79245d1aa8320339
        Date:   Mon Feb 15 10:45:33 2016 -0500

        We have added an animal

    commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
        Date:   Mon Feb 15 10:44:18 2016 -0500

        Initial commit

Finora così bene, giusto? Nulla sembra fuori dall'ordinario nell'output del log. Si supponga ora di aver cambiato idea e di aver deciso di unire il ramo di frutta:

>git merge fruit
    
    Auto-merging test.txt
    CONFLICT (content): Merge conflict in test.txt
    Automatic merge failed; fix conflicts and then commit the result.

Uh-oh, un conflitto di unione. Dopo alcune considerazioni, si decide di usare l'intero test.txt file dal ramo di frutta. In genere si userebbe un qualche tipo di editor di testo o strumento di unione, ma verrà ricreato solo l'intero file, poiché si tratta solo di due righe:

> echo "some content" > test.txt
> echo "bananas" >> test.txt
> git commit -am "Fixed merge conflict"

Si esaminerà ora la cronologia per il test.txt file:

> git log test.txt
    
    commit fdd4dfd816c4efebc5bdb240f49e934e299db581
        Date:   Mon Feb 15 10:51:06 2016 -0500

        We have added a fruit

    commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
        Date:   Mon Feb 15 10:44:18 2016 -0500

        Initial commit

Abbastanza sicuro, non vengono visualizzate modifiche dal primo esperimento nel log, né viene visualizzato il merge. Sono ancora lì? Git ha eliminato completamente le modifiche?

> git log --full-history test.txt

Come si può notare, anche se il log è stato semplificato senza il full-history flag, Git ha mantenuto tutte le modifiche:

> commit 5d0bb77a24e265dc154654fb3b5be331b53bf977
    Merge: 6b33d99 fdd4dfd
        Date:   Mon Feb 15 10:59:34 2016 -0500

        Fixed merge conflict

    commit fdd4dfd816c4efebc5bdb240f49e934e299db581
        Date:   Mon Feb 15 10:51:06 2016 -0500

        We have added a fruit

    commit 6b33d99b996c430a60c9552b79245d1aa8320339
        Date:   Mon Feb 15 10:45:33 2016 -0500

        We have added an animal

    commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
        Date:   Mon Feb 15 10:44:18 2016 -0500

        Initial commit

Riepilogo della semplificazione della cronologia Git

La cosa della semplificazione della storia è che la maggior parte del tempo non si noterà mai. Tuttavia, quando un conflitto di merge va storto e si vuole sapere cosa è accaduto, potrebbe essere necessario esaminare la cronologia dei log Git e chiedersi dove sono state apportate le modifiche.

Ora, invece di prendere il panico, sai che:

• La semplificazione della cronologia per i file è attivata per impostazione predefinita
• Il --full-history flag ti darà una cronologia dei file più completa

Aggiornamento: dopo aver scritto questo articolo, Azure DevOps Services ha introdotto numerose opzioni di visualizzazione cronologia straordinarie sul Web. Ciò significa che se non si vuole eseguire lo slogging tramite la riga di comando, è sufficiente estrarre il file per cui si vuole visualizzare la cronologia in Esplora risorse e verrà visualizzato il filtro cronologia seguente in cui è possibile specificare visualizzazioni cronologiche semplici o non semplici:

(c) 2016 Microsoft Corporation. Tutti i diritti sono riservati. Questo documento viene fornito "così come è". Le informazioni e le visualizzazioni espresse in questo documento, inclusi URL e altri riferimenti al sito Web Internet, possono cambiare senza preavviso. L'utente si assume tutti i rischi derivanti dal suo utilizzo.

Questo documento non concede alcun diritto legale su qualsiasi proprietà intellettuale di qualsiasi prodotto Microsoft. È consentito copiare e utilizzare il presente documento solo a scopo di riferimento interno.