Che cos’è Git?

Alzi la mano chi, nella sua vita informatica ha mai dovuto gestire il problema delle modifiche di un file.

Mmmm, non lo cancello. Se poi dopo mi serve?
Non funziona. Torno indietro alla versione prima.

Voi conoscete Git?

Git è un software di controllo di versione (Version Control Systems o VCS)…

Ok, facciamo un passo indietro…

Che cos’è il controllo di versione?

Già meglio…

Il controllo di versione è un sistema che memorizza i cambiamenti di file o directory nel tempo così da poter richiamare una versione specifica in un secondo momento.
Spieghiamo un po’ come siamo arrivati a GIT e le differenze con gli altri controlli di versione.

Sistema di controllo di versione locale

Partiamo dalle persone che perdono le vecchie versioni dei file.

Ah ma non funziona il Ctrl+Z?

Altri creano delle copie.

File_1.jpg, File_1_Copia (1).jpg, File_1_Copia (2).jpg, File_1_Copia della Copia (1).jpg,…

Classico esempio di confusione

Arrivando a chi gestisce le diverse versioni e modifiche copiando i file in un’altra cartella, magari una directory chiamata con la data della modifica.

Tutti questi approcci sono molto comuni perché sono semplici e banali, ma con questi modi è anche facilissimo sbagliare, fare errori e soprattutto perdere tutto.

Per far fronte a questi problemi, gli sviluppatori inventarono software di VCS locali che avevano un database interno che manteneva tutti i cambiamenti dei file sotto controllo di revisione.

VCS locale

Sistemi di Controllo di Versione Centralizzati

Successivamente subentrò anche un secondo problema: la collaborazione con altre persone.
A quel punto, vennero sviluppati sistemi di controllo di versione centralizzati (CVCS).

Questi sistemi (come Subversion o noto anche come SVN) hanno un unico server che contiene tutte le versioni dei file.
Tutti gli utenti scaricano i file dal server centrale.

VCS Centralizzata

Questi strumenti offrono numeri vantaggi rispetto ai VCS locali quando si deve lavorare in team.
Gli amministratori, per esempio, sanno cos’ha modificato un’altra persona e possono decidere chi può fare cosa.

Tra i contro della soluzione c’è quella che se il server centralizzato va giù, nessuno può salvare una nuova versione (commit), se il disco rigido del server si danneggia (e non ci sono backup) si perde tutto (ad eccezione di quanto un singolo ha in locale nella sua macchina).

Sistemi di Controllo di Versione Distribuiti

E qui entrano in gioco i Sistemi di Controllo di Versione Distribuiti (DVCS). In un DVCS (tra cui anche Git), i client fanno una copia dell’archivio (repository), completa di tutta la propria storia; in questo modo se un server smettesse di funzionare, il repository di un qualsiasi client potrebbe essere copiato sul server per ripristinarlo.

VCS Decentralizzata

Gli utenti possono lavorare tranquillamente in locale (commit) e successivamente inviare tutte le modifiche al repository remoto (push).

Quindi, cos’é Git?

La principale differenza tra Git e gli altri VCS (inclusi SVN e simili), è come Git salva i suoi dati. La maggior parte degli altri sistemi salvano l’informazione come una lista di modifiche ai file (controllo di versione su base delta).

Memorizzazione dei file e lista dei cambiamenti su SVN

Git, invece, considera i propri dati come una sequenza di istantanee (snapshot). Ogni volta che viene registrato lo stato di un progetto (commit), Git fa un’immagine di tutti i file in quel momento, salvando un riferimento allo snapshot.
Per essere efficiente, se alcuni file non sono cambiati, Git non li risalva, ma crea un collegamento al file già salvato in precedenza.
Git considera, quindi, i propri dati come un flusso di istantanee.

Memorizzazione dei file e lista dei cambiamenti su GIT

Quasi tutte le operazioni sono locali

La maggior parte delle operazioni in Git, necessitano solo di file e risorse locali. Per esempio, per navigare la cronologia di un progetto, Git non ha bisogno di connettersi al server per scaricarla e per poi mostrarla — viene letta direttamente dal repository locale. Per vedere le modifiche tra la versione corrente e la versione di un mese fa, Git può accedere al file com’era un mese fa e calcolare le differenze in locale, senza dover chiedere nulla al server remoto.

Da offline si può lavorare ed eseguire commit locali per poi uploadarli quando si è di nuovo online.

Git e i checksum (?!)

E’ impossibile cambiare il contenuto dei file o delle directory senza che Git se ne accorga.

Git utilizza un checksum che non è altro che una sequenza di bit. Il meccanismo che Git usa per fare questo checksum è un hash chiamato SHA-1. Si tratta di una stringa di 40 caratteri, composta da caratteri esadecimali (0–9 ed a–f) e calcolata in base al contenuto di file o della struttura della directory. Un hash SHA-1 assomiglia a qualcosa come:

24b9da6552252987aa493b52f8696cd6d3b00373

In Git il riferimento ad un file non è basato sul nome del file, ma sull’hash del suo contenuto.

I tre stati

I file in Git possono essere in tre stati principali: modified (modificati), staged (in stage) e committed (committati).

modified. Il file è stato modificato, ma non è ancora stato committato nel database.

staged. I file sono stati contrassegnati allo scopo di venire inseriti nello snapshot al prossimo commit.

committed. Il file è registrato al sicuro nel database locale.

Gli stati di Git

La working directory, o meglio la cartella di lavoro, è un checkout di una versione specifica del progetto. Questi file vengono estratti dal repository e messi ne disco per essere usati o modificati.

L’area di stage, invece, è un file, contenuto generalmente nella directory di Git, con tutte le informazioni riguardanti il prossimo commit.

La directory di Git è dove vengono salvati i metadati e il database degli oggetti del progetto.

Il flusso di lavoro (workflow) di base funziona così:

1. I file vengono modificati nella working directory.
2. Vengono selezionati per lo stage solo i cambiamenti che si vuole includere nel prossimo commit.
3. Viene fatto un commit, ovvero vengono salvati in una istantanea permanente (snapshot) i file che erano nell’area di stage.

Fonti: https://git-scm.com