Git - Concetti di base

Sistema di controllo della versione

Version Control System (VCS) è un software che aiuta gli sviluppatori di software a lavorare insieme e mantenere una cronologia completa del loro lavoro.

Di seguito sono elencate le funzioni di un VCS:

• Consente agli sviluppatori di lavorare contemporaneamente.
• Non consente la sovrascrittura delle modifiche reciproche.
• Mantiene una cronologia di ogni versione.

Di seguito sono riportati i tipi di VCS:

• Sistema di controllo della versione centralizzato (CVCS).
• Sistema di controllo della versione distribuito / decentralizzato (DVCS).

In questo capitolo, ci concentreremo solo sul sistema di controllo della versione distribuito e specialmente su Git. Git rientra nel sistema di controllo della versione distribuito.

Sistema di controllo della versione distribuito

Il sistema di controllo della versione centralizzato (CVCS) utilizza un server centrale per archiviare tutti i file e consente la collaborazione in team. Ma il principale svantaggio di CVCS è il suo singolo punto di errore, ovvero il guasto del server centrale. Sfortunatamente, se il server centrale si blocca per un'ora, durante quell'ora nessuno può collaborare. E anche nel peggiore dei casi, se il disco del server centrale viene danneggiato e non è stato eseguito il backup corretto, perderai l'intera cronologia del progetto. Qui, entra in scena il sistema di controllo della versione distribuito (DVCS).

I client DVCS non solo eseguono il check out dell'istantanea più recente della directory, ma rispecchiano anche completamente il repository. Se il server si arresta, il repository da qualsiasi client può essere copiato di nuovo sul server per ripristinarlo. Ogni checkout è un backup completo del repository. Git non si basa sul server centrale ed è per questo che puoi eseguire molte operazioni quando sei offline. Puoi eseguire il commit delle modifiche, creare rami, visualizzare i registri ed eseguire altre operazioni quando sei offline. È necessaria una connessione di rete solo per pubblicare le modifiche e prendere le ultime modifiche.

Vantaggi di Git

Gratuito e open source

Git è rilasciato con licenza open source GPL. È disponibile gratuitamente su Internet. Puoi utilizzare Git per gestire progetti immobiliari senza pagare un solo centesimo. Trattandosi di un open source, puoi scaricare il suo codice sorgente ed eseguire anche modifiche in base alle tue esigenze.

Veloce e piccolo

Poiché la maggior parte delle operazioni vengono eseguite localmente, offre un enorme vantaggio in termini di velocità. Git non si basa sul server centrale; ecco perché, non è necessario interagire con il server remoto per ogni operazione. La parte centrale di Git è scritta in C, che evita i sovraccarichi di runtime associati ad altri linguaggi di alto livello. Sebbene Git rispecchi l'intero repository, la dimensione dei dati sul lato client è piccola. Questo illustra l'efficienza di Git nella compressione e nell'archiviazione dei dati sul lato client.

Backup implicito

Le possibilità di perdere i dati sono molto rare quando sono presenti più copie. I dati presenti su qualsiasi lato client rispecchiano il repository, quindi possono essere utilizzati in caso di crash o danneggiamento del disco.

Sicurezza

Git utilizza una funzione hash crittografica comune chiamata funzione hash sicura (SHA1), per denominare e identificare gli oggetti all'interno del proprio database. Ogni file e commit viene riepilogato e recuperato dal proprio checksum al momento del checkout. Ciò implica che è impossibile cambiare file, data e messaggio di commit e qualsiasi altro dato dal database Git senza conoscere Git.

Non c'è bisogno di hardware potente

In caso di CVCS, il server centrale deve essere abbastanza potente da soddisfare le richieste dell'intero team. Per i team più piccoli, non è un problema, ma con l'aumentare delle dimensioni del team, i limiti hardware del server possono essere un collo di bottiglia delle prestazioni. In caso di DVCS, gli sviluppatori non interagiscono con il server a meno che non debbano eseguire il push o il pull delle modifiche. Tutto il lavoro pesante avviene sul lato client, quindi l'hardware del server può essere davvero molto semplice.

Ramificazione più facile

CVCS utilizza un meccanismo di copia economico, se creiamo un nuovo ramo, copierà tutti i codici nel nuovo ramo, quindi richiede tempo e non è efficiente. Inoltre, l'eliminazione e l'unione di rami in CVCS è complicata e richiede tempo. Ma la gestione dei rami con Git è molto semplice. Ci vogliono solo pochi secondi per creare, eliminare e unire i rami.

Terminologie DVCS

Repository locale

Ogni strumento VCS fornisce un luogo di lavoro privato come copia di lavoro. Gli sviluppatori apportano modifiche nel loro ambiente di lavoro privato e, dopo il commit, queste modifiche diventano parte del repository. Git fa un ulteriore passo avanti fornendo loro una copia privata dell'intero repository. Gli utenti possono eseguire molte operazioni con questo repository come aggiungere file, rimuovere file, rinominare file, spostare file, eseguire il commit delle modifiche e molte altre.

Directory di lavoro e area o indice di staging

La directory di lavoro è il luogo in cui vengono estratti i file. In altri CVCS, gli sviluppatori generalmente apportano modifiche e inviano le modifiche direttamente al repository. Ma Git utilizza una strategia diversa. Git non tiene traccia di ogni singolo file modificato. Ogni volta che esegui il commit di un'operazione, Git cerca i file presenti nell'area di staging. Solo i file presenti nell'area di staging vengono considerati per il commit e non tutti i file modificati.

Vediamo il flusso di lavoro di base di Git.

Step 1 - Si modifica un file dalla directory di lavoro.

Step 2 - Aggiungi questi file all'area di staging.

Step 3- Esegui un'operazione di commit che sposta i file dall'area di staging. Dopo l'operazione push, memorizza le modifiche in modo permanente nel repository Git.

Supponiamo di aver modificato due file, ovvero "sort.c" e "search.c", e di volere due commit diversi per ciascuna operazione. Puoi aggiungere un file nell'area di staging e fare il commit. Dopo il primo commit, ripetere la stessa procedura per un altro file.

# First commit
[bash]$ git add sort.c

# adds file to the staging area
[bash]$ git commit –m “Added sort operation”

# Second commit
[bash]$ git add search.c

# adds file to the staging area
[bash]$ git commit –m “Added search operation”

Blob

Blob sta per Binario Large Object. Ogni versione di un file è rappresentata da BLOB. Un BLOB contiene i dati del file ma non contiene metadati sul file. È un file binario e nel database Git è denominato hash SHA1 di quel file. In Git, i file non sono indirizzati da nomi. Tutto è orientato al contenuto.

Alberi

Tree è un oggetto, che rappresenta una directory. Contiene i BLOB e altre sottodirectory. Un albero è un file binario che memorizza i riferimenti a BLOB e alberi denominati anche comeSHA1 hash dell'oggetto albero.

Si impegna

Il commit mantiene lo stato corrente del repository. Un commit è anche denominato daSHA1hash. È possibile considerare un oggetto commit come un nodo dell'elenco collegato. Ogni oggetto commit ha un puntatore all'oggetto commit genitore. Da un dato commit, puoi tornare indietro guardando il puntatore genitore per visualizzare la cronologia del commit. Se un commit ha più commit padre, quel particolare commit è stato creato unendo due rami.

Rami

I rami vengono utilizzati per creare un'altra linea di sviluppo. Per impostazione predefinita, Git ha un ramo principale, che è lo stesso di trunk in Subversion. Di solito, viene creato un ramo per lavorare su una nuova funzionalità. Una volta completata la funzionalità, viene nuovamente unita al ramo principale e cancelliamo il ramo. Ogni ramo è referenziato da HEAD, che punta all'ultimo commit nel ramo. Ogni volta che effettui un commit, HEAD viene aggiornato con l'ultimo commit.

Tag

Il tag assegna un nome significativo con una versione specifica nel repository. I tag sono molto simili ai rami, ma la differenza è che i tag non sono modificabili. Significa che il tag è un ramo, che nessuno intende modificare. Una volta che un tag è stato creato per un particolare commit, anche se crei un nuovo commit, non verrà aggiornato. Di solito, gli sviluppatori creano tag per le versioni del prodotto.

Clone

L'operazione di clonazione crea l'istanza del repository. L'operazione di clonazione non solo controlla la copia di lavoro, ma rispecchia anche l'intero repository. Gli utenti possono eseguire molte operazioni con questo repository locale. L'unico momento in cui viene coinvolta la rete è quando le istanze del repository vengono sincronizzate.

Tirare

L'operazione di pull copia le modifiche da un'istanza di repository remota a una locale. L'operazione pull viene utilizzata per la sincronizzazione tra due istanze del repository. È lo stesso dell'operazione di aggiornamento in Subversion.

Spingere

L'operazione push copia le modifiche da un'istanza di repository locale a una remota. Viene utilizzato per archiviare le modifiche in modo permanente nel repository Git. È lo stesso dell'operazione di commit in Subversion.

TESTA

HEAD è un puntatore, che punta sempre all'ultimo commit nel ramo. Ogni volta che effettui un commit, HEAD viene aggiornato con l'ultimo commit. Le teste dei rami vengono immagazzinate.git/refs/heads/ directory.

[CentOS]$ ls -1 .git/refs/heads/
master

[CentOS]$ cat .git/refs/heads/master
570837e7d58fa4bccd86cb575d884502188b0c49

Revisione

La revisione rappresenta la versione del codice sorgente. Le revisioni in Git sono rappresentate da commit. Questi commit sono identificati daSHA1 hash sicuri.

URL

L'URL rappresenta la posizione del repository Git. L'URL di Git è archiviato nel file di configurazione.

[tom@CentOS tom_repo]$ pwd
/home/tom/tom_repo

[tom@CentOS tom_repo]$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = [email protected]:project.git
fetch = +refs/heads/*:refs/remotes/origin/*