Informazioni sulla cronologia git

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

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 cronologia è incredibilmente importante ed è il motivo principale per cui gli utenti trovano Git confuso.

Nota

Se non è possibile trovare una modifica nella cronologia Git che si è appresa, altre informazioni sul funzionamento della semplificazione della cronologia Git in Git perdono 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.

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. Il nome main è dovuto al nome predefinito per il ramo mainline in un repository Git. I rami sono puntatori a commit specifici, motivo per cui la diramazione è così leggera e semplice 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, eseguirò 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 nell'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 miei 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, si userà 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 incluse 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 i conflitti.

Storia nel mondo reale

Di seguito è riportato un esempio di cronologia Git che è più simile 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 comprende come i rami e i merge creano la forma del grafico, questo non dovrebbe essere troppo spaventoso!