Il controllo di versione è un sistema che gestisce i file sorgenti sui quali lavori ogni giorno. Traccia i cambiamenti che fai ad ogni singolo file, così da poter magari tornare in dietro nel tempo ad una versione specifica, se lo desideri.
Di base, questo sistema vive e lavora sul tuo computer ma potenzialmente è possibile interagire con server remoti così da poter condividere il codice più facilmente con i collaboratori.
Un VCS (Version Control System) ti permette quindi di avere una panoramica completa sul tuo progetto, permettendoti di visualizzare le modifiche che hai fatto nel corso del tempo, o che magari hanno fatto gli altri e, se hai fatto qualche guaio, anche di recuperare la situazione molto facilmente.
Inoltre, se sei un developer con il laptop sempre nello zaino, puoi in ogni momento sincronizzare il tuo lavoro con il punto dov’eri rimasto, grazie ai server remoti dove salvi gli snapshot del tuo progetto, e ricominciare a scrivere codice al volo.
Sistemi di Controllo di Versione Distribuiti
Senza addentrarci troppo nello specifico, sappi che Git (come anche Mercurial) adotta un sistema di controllo di versione distribuito DVCS (Distributed Version Control System). In questi sistemi ogni client possiede una copia completa del repository (cioè dell’insieme del file) oltre ovviamente all’ultimo snapshot (l’ultimo stato) dell’intero progetto. Non c’è un server centrale dal quale dipendere, quindi puoi lavorare in piena autonomia con il tuo codice ed eseguire tutte le operazioni che Git mentre non sei connesso al server. Per capire quanto sia flessibile, basti pensare che una nostra copia locale potrebbe ripristinare un intero server, perché in locale avremmo sempre una copia completa dei dati che potrebbe essere usata come backup.
Se poi aggiungiamo che uno o più repository potrebbero risiedere su server remoti, significa che possiamo collaborare con gruppi di persone diverse per ciascun progetto e avere una copia in remoto del nostro repository.
[[[adv]]
Ambiente di lavoro
Questa è la sezione più importante di questo capitolo perché ci accompagnerà per tutto il nostro percorso e permette di capire a fondo come lavora Git. Per prima cosa, consideriamo la nostra working directory, ovvero la cartella dove ci sono i file del nostro progetto e sui quali lavoriamo. Questa può anche essere vuota, all’inizio. Git crea automaticamente un’area di stage dove i nostri file saranno in coda per essere committati, ovvero salvati nel database locale.
Un file può trovarsi in uno di questi stati:
- modified quando il file è stato modificato ma non ancora commitato
- staged ovvero che è stato messo nell’area di stage e pronto per il commit
- commited quando è passato dall’area di stage al commit ed è al sicuro nel database locale
Ricapitolando: quando saremo pronti per farlo, dopo aver lavorato sui nostri file, metteremo i file modificati nell’area di stage e poi effettueremo il commit per salvare questi file e quindi creare uno snapshot permanente del nostro lavoro.
Com’è fatto uno snapshot
Uno snapshot è un’istantanea del progetto. Infatti ogni volta che ne eseguiremo il comando git commit (che vedremo in seguito) a tutti in effetti Git crea un’immagine di tutti file presenti in quel momento e salva un riferimento a questo istante in modo da poterlo riconoscere in futuro. Sotto il cofano, Git in realtà non salva nuovamente tutti i file per ogni commit, ma crea per ciascuno di essi un collegamento alla sua versione precedente già salvata.
Puoi lavorare offline
Questa sequenza di operazioni viene sempre eseguita localmente, cioè sul tuo computer. Tutta la cronologia dei cambiamenti è sempre con te, in una cartella dedicata e potrai recuperare facilmente dei file del tuo progetto o semplicemente capire quali modifiche hai fatto su uno o più file nel corso del tempo. Tutto ciò ti permette di lavorare anche offline e poi fare l’upload una volta che sei connesso.
Se non l’avete già fatto, nel prossimo capitolo vedremo come installare Git.