1.3 Per Iniziare - Cos’é Git?

La principale differenza tra Git e gli altri VCS (inclusi Subversion e simili), è come Git considera i suoi dati. Concettualmente la maggior parte degli altri sistemi salvano l’informazione come una lista di modifiche ai file. Questi altri sistemi (CVS, Subversion, Perforce, Bazaar e così via), considerano le informazioni che memorizzano come un insieme di file, con le relative modifiche fatte nel tempo (questo viene normalmente descritto come controllo di versione su base delta).

Git non considera i dati né li registra in questo modo. Git considera i propri dati più come una sequenza di istantanee (snapshot) di un mini filesystem. Con Git, ogni volta che registri (commit), o salvi lo stato del tuo progetto, fondamentalmente lui 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 semplicemente un collegamento al file precedente già salvato. Git considera i propri dati più come un flusso di istantanee.

Questa è una distinzione importante tra Git e pressocché tutti gli altri VCS. Git riconsidera quasi tutti gli aspetti del controllo di versione che la maggior parte degli altri sistemi ha copiato dalle generazioni precedenti. Questo rende Git più simile a un mini filesystem con a disposizione strumenti incredibilmente potenti che un semplice VCS. Esploreremo alcuni benefici che ottieni pensando in questo modo ai tuoi dati e vedremo le ramificazioni in Git nel [ch03-git-branching].

La maggior parte delle operazioni in Git, necessitano solo di file e risorse locali per operare — generalmente non occorrono informazioni da altri computer della rete. Se sei abituato ad un CVCS in cui la maggior parte delle operazioni sono soggette alle latenze di rete, questo aspetto di Git ti farà pensare che gli Dei della velocità abbiano benedetto Git con poteri soprannaturali. Poiché hai l’intera storia del progetto sul tuo disco locale, molte operazioni sembrano quasi istantanee.

Per esempio, per navigare la storia di un progetto, Git non ha bisogno di connettersi al server per scaricarla e per poi mostrarla — la legge direttamente dal tuo database locale. Questo significa che puoi vedere la storia del progetto quasi istantaneamente. Se vuoi vedere le modifiche introdotte tra la versione corrente e la versione di un mese fa di un file, Git può accedere al file com’era un mese fa e calcolare le differenze localmente, invece di dover chiedere a un server remoto di farlo o di scaricare dal server remoto una versione precedente del file, per poi farlo in locale.

Questo significa anche che sono pochissime le cose che non puoi fare se sei offline o non sei connesso alla VPN. Se sei in aereo o sul treno e vuoi fare un po' di lavoro, puoi eseguire commit tranquillamente (alla tua copia locale, ricordi?) in attesa di essere di nuovo connesso per fare l’upload. Se vai a casa e il tuo client VPN non funziona correttamente, puoi lavorare ugualmente. In molti altri sistemi questo è impossibile o molto penoso. Con Perforce, per esempio, puoi fare ben poco se non sei connesso al server; e con Subversion e CVS, puoi modificare i file, ma non puoi registrare le modifiche sul tuo database (perché il database è offline). Tutto ciò potrebbe non sembrarti una gran cosa, ma potrebbe sorprenderti quanta differenza possa fare.

Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di basso livello di Git ed è intrinseca della sua filosofia. Non può capitare che delle informazioni in transito si perdano o che un file si corrompa senza che Git non sia in grado di accorgersene.

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 in Git. Un hash SHA-1 assomiglia a qualcosa come:

Vedrai questi hash dappertutto in Git perché li usa tantissimo. Infatti Git salva qualsiasi cosa nel suo database, e il riferimento ad un file non è basato sul nome del file, ma sull’hash del suo contenuto.

Quasi tutte le azioni in Git aggiungono dati al database di Git. È difficile fare qualcosa che non sia annullabile o che cancelli i dati in una qualche maniera. Come con gli altri VCS, puoi perdere o fare confusione con le modifiche che non hai ancora registrato (commit), ma dopo aver registrato uno snapshot in Git, è veramente difficile perderle, specialmente se regolarmente fai il push del tuo database su un altro repository.

Questo rende piacevole l’uso di Git perché sappiamo che possiamo sperimentare senza il pericolo di causare danni pesanti. Per un maggior approfondimento su come Git salvi i dati e come tu possa recuperare quelli che sembrino persi, consulta il Undoing Things.

Attenzione adesso — qui c’è la cosa principale da ricordare di Git se vuoi affrontare al meglio il processo di apprendimento. I file in Git possono essere in tre stati principali: modified (modificati), staged (in stage) e committed (committati). * Modificato significa che il file è stato modificato, ma non è ancora stato committato nel database. * In stage significa che hai contrassegnato un file, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit. * Committato significa che il file è registrato al sicuro nel database locale.

Questo ci porta alle tre sezioni principali di un progetto Git: l’albero di lavoro, l’area di stage e la directory di Git,

L’albero di lavoro è un checkout di una versione specifica del progetto. Questi file vengono estratti dal database compresso nella directory di Git, e salvati sul disco per essere usati o modificati.

L’area di stage è un file, contenuto generalmente nella directory di Git, con tutte le informazioni riguardanti la tua prossima commit. Il suo nome tecnico nel gergo di Git è indice, ma l’espressione area di stage (area di sosta, ndt) funziona altrettanto bene.

La directory di Git è dove Git salva i metadati e il database degli oggetti del tuo progetto. Questa è la parte più importante di Git, ed è ciò che viene copiato quando si clona un repository da un altro computer.

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

Se una particolare versione di un file è nella directory git, viene considerata già committata (committed). Se il file è stato modificato, ma è stato aggiunto all’area di staging, è in stage. E se è stato modificato da quando è stata estratto, ma non è in stage, è modificato. In Git Basics, imparerai di più su questi stati e come trarne vantaggio o saltare la parte di staging.