Informazioni sulla cronologia git

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

Git archivia la cronologia come grafico degli snapshot, denominati commit, dell'intero repository. Ogni commit contiene anche un puntatore a uno o più commit precedenti. I commit possono avere più elementi padre, creando una cronologia simile a un grafico anziché a una linea retta. Questa differenza nella storia è incredibilmente importante ed è il motivo principale per cui gli utenti trovano confusione in Git.

Nota

Se non è possibile trovare una modifica nella cronologia Git creata, vedere La semplificazione della cronologia Git ha perso le modifiche: esaminare la semplificazione della cronologia di Git.

Nozioni di base sulla cronologia dei commit

Iniziare con un esempio di cronologia semplice: un repository con 3 commit lineari.

Il commit A è l'elemento padre del commit B e il commit B è l'elemento padre del commit C. Questa storia è molto simile a un CVCS. La freccia che punta al commit C è un ramo. È denominato main perché è il nome predefinito per il ramo mainline in un repository Git. I rami sono puntatori a commit specifici, motivo per cui la diramazione è così semplice e leggera in Git.

Una differenza fondamentale in Git rispetto a CVCS è che ho la mia copia completa del repository. È necessario mantenere sincronizzato il repository locale con il repository remoto ottenendo i commit più recenti dal repository remoto. A tale scopo, eseguire il pull del ramo main con il comando seguente:

git pull origin main

In questo modo vengono copiati tutti i commit dal main ramo del repository remoto (chiamato origin per impostazione predefinita) al main ramo del repository locale. L'operazione pull ha copiato un nuovo commit e il main ramo nel repository locale punta ora a questo nuovo commit.

Informazioni sulla cronologia dei rami

A questo momento si vuole apportare una modifica al codice. È comune avere più rami attivi in cui si lavora su diverse funzionalità in parallelo. Questo è in contrasto con CVCS in cui i nuovi rami sono pesanti e raramente creati. Il primo passaggio consiste nel eseguire il checkout in un nuovo ramo usando il comando seguente:

git checkout -b cool-new-feature

Si tratta di un collegamento che combina due comandi: git branch cool-new-feature per creare il ramo seguito da git checkout cool-new-feature per iniziare a lavorare nel ramo.

Due rami puntano ora allo stesso commit. Nel ramo verranno apportate alcune modifiche cool-new-feature in due nuovi commit, E e F.

I commit sono raggiungibili dal cool-new-feature ramo perché li ho creati in quel ramo. La funzionalità è stata completata e si vuole unirla a main. A tale scopo, usare il comando seguente:

git merge cool-feature main

La struttura del grafo della cronologia diventa visibile quando è presente un'unione. Git crea un nuovo commit quando il ramo è stato unito in un altro ramo. Si tratta di un commit di merge. Non sono state apportate modifiche in questo commit di merge perché non sono presenti conflitti. In caso di conflitti, il commit di merge includerà le modifiche necessarie per risolvere tali conflitti.

Storia nel mondo reale

Di seguito è riportato un esempio di cronologia Git che assomiglia più strettamente al codice nello sviluppo attivo in un team. Esistono tre persone che uniscono i commit dai propri rami nel ramo principale nello stesso momento.

Ora che si capisce come i rami e i merge creano la forma del grafico, questo non dovrebbe essere troppo spaventoso!