Che cos'è Git? - La guida completa a Git

Se hai mai letto qualcosa su coding, programmazione o sviluppo software, hai sentito parlare di Git.

Questo pratico strumento (e gratuito) è il sistema di controllo di versione più popolare al mondo. È così diffuso che è utilizzato da oltre il 90% degli sviluppatori professionisti, per non parlare dei professionisti in altri settori.

Per molti versi, Git è praticamente sinonimo di controllo di versione. Ma cos'è il controllo di versione e perché è così importante?

Unisciti a noi per un tuffo profondo nel Gitverse. Qui diamo uno sguardo più da vicino a tutto ciò che riguarda Git: cos'è, chi lo usa e la sua storia.

Che cos'è Git?

Git è un sistema di controllo di versione distribuito (dVCS). Come suggerisce il nome, il controllo di versione riguarda il controllo e il tracciamento delle diverse versioni di un dato progetto. 

Che cos'è un sistema di controllo di versione (VCS)?

Un VCS traccia e registra le modifiche a qualsiasi file (o gruppo di file) permettendoti di richiamare in seguito, quando necessario, specifiche iterazioni. I VCS sono talvolta chiamati sistemi di gestione del codice sorgente (SCM) o sistemi di controllo delle revisioni (RCS).

Il controllo di versione consente a numerosi membri del team di lavorare in modo collaborativo su un progetto, anche se non si trovano nella stessa stanza o addirittura nello stesso paese. 

Per esempio, diciamo che sei un cantautore. Stai lavorando a casa a una nuova canzone che hai scritto, ma non ti soddisfa del tutto. Decidi quindi di collaborare con altri due autori per affrontare le parti che necessitano di lavoro.

Tu e gli altri due autori iniziate a fare modifiche al testo e alla partitura, lavorando ciascuno in modo indipendente. Quando gli altri musicisti ti inviano le loro versioni del brano, alcune delle modifiche ti piacciono, altre meno.

Ora immagina di poter vedere ogni modifica in ciascuna versione della canzone, poterle provare per sentire come suonano e poi sincronizzare tra le versioni solo le modifiche che ti piacciono.

È esattamente ciò che consente di fare Git. Ognuno può lavorare a un progetto in locale (sul proprio computer), salvare le modifiche che funzionano e poi sincronizzarle su un repository Git in modo che altri possano vedere la versione aggiornata.

Di solito Git è considerato uno strumento per lo sviluppo software, e lo è, ma può essere usato per il controllo di versione (versioning) di qualsiasi tipo di file: righe di codice, il layout di un nuovo sito web o una canzone. 

I vantaggi del controllo di versione

Oltre a essere uno strumento utile per il lavoro collaborativo, ci sono altri vantaggi del controllo di versione:

• Modifiche attribuibili. Ogni modifica effettuata può essere attribuita a un membro del team. 
• Tracciamento approfondito che semplifica il ripristino. Poiché ogni modifica è tracciata, anche le più piccole, è facile tornare a una versione precedente se necessario. Come puoi immaginare, questa è una funzionalità fondamentale nello sviluppo software.
• Migliore organizzazione e comunicazione. I messaggi di commit, ovvero i messaggi che invii al team per spiegare perché hai apportato una modifica, favoriscono una buona comunicazione tra i membri del team. Inoltre, tornano molto utili se dimentichi quali modifiche hai fatto in passato!
• Concorrenza. Nei progetti software, gli sviluppatori apportano molte modifiche al codice sorgente. Di solito ci sono numerosi sviluppatori che lavorano su cose diverse. Uno potrebbe ottimizzare il codice esistente per migliorarne la sicurezza mentre un altro lavora a una nuova funzionalità. Git consente a questi sviluppatori di lavorare in concorrenza aiutando a prevenire conflitti tra le modifiche di ciascuno. 
• Branching e merging. I membri del team possono creare branch separati su cui lavorare e poi unire le proprie modifiche nel branch principale. I branch sono temporanei e possono essere eliminati dopo un merge. 

Git è l'unico sistema di controllo di versione?

No, Git non è l'unico VCS, ma è il più popolare ed è considerato lo strumento standard de facto. Altri sistemi di controllo versione popolari sono Fossil, Mercurial e Subversion. 

Esistono leggere differenze tra i sistemi, anche nel modo in cui gestiscono funzioni fondamentali come branching e merging, ma l'idea di fondo è la stessa. La principale differenza tra i sistemi, però, è se siano centralizzati o distribuiti. 

Sistemi di controllo di versione centralizzati e distribuiti

Sia i sistemi centralizzati che quelli distribuiti, come Git, svolgono la stessa funzione. 

La differenza chiave è che i sistemi centralizzati hanno un server centrale su cui i membri del team inviano le versioni più recenti del loro lavoro. Puoi pensarla un po' come avere un singolo progetto centrale che tutti condividono. 

Con i VCS distribuiti, i membri del team hanno una copia locale (clone) dell'intera cronologia del progetto sul proprio dispositivo, quindi non devono essere online per apportare modifiche o lavorare al proprio codice. Invece di un server centralizzato, ottengono questo clone da un repository online.

Quando gli sviluppatori lavorano con Git, il clone del progetto di ogni membro del team è un repository che può contenere tutte le modifiche fin dall'inizio del progetto.

La storia di Git

Git è stato sviluppato nel 2005 dall'ingegnere software finlandese Linus Torvalds, noto anche per aver sviluppato il kernel del sistema operativo Linux.

Git è stato creato per rispondere a un'esigenza immediata. Prima della sua invenzione, gli sviluppatori Linux in tutto il mondo usavano il software proprietario BitKeeper, anch'esso un dVCS. 

Essendo un software di proprietà aziendale, ciò causava qualche attrito tra gli sviluppatori Linux, la maggior parte dei quali sosteneva l'etica open source. 

In cambio dell'uso gratuito del software, BitMover, l'azienda dietro BitKeeper, impose restrizioni alla comunità Linux. Secondo il Linux Journal, tra queste restrizioni c'era il divieto di lavorare a progetti di controllo di versione concorrenti. 

In una mossa forse inevitabile, uno sviluppatore Linux iniziò a fare reverse engineering di BitKeeper nel tentativo di creare un prodotto open source. Fedeli alla loro posizione, BitMover smise di fornire servizi al kernel Linux e il sistema di sviluppo distribuito precipitò nell'incertezza.

Per risolvere questo rompicapo, Torvalds sospese il lavoro su Linux per la prima volta dal 1991 e creò Git, rilasciandone una versione stabile a pochi mesi dall'inizio dello sviluppo. 

Curiosamente, prima che il kernel Linux adottasse BitKeeper, gli sviluppatori inviavano a Torvalds le loro patch (modifiche) in modo indipendente e lui le integrava quando necessario. E nel 2016, 11 anni dopo il rilascio di Git, BitKeeper è diventato open source. 

Come ha ottenuto il nome Git?

Nel primo commit di codice di Linus Torvalds su Git nel 2005, aggiunse un file readme che offre qualche spunto sul perché il programma si chiami Git. Ecco una parte di quel file:

A meno che tu non preferisca la versione più edulcorata Global Information Tracker, il nome Git è un'ironica strizzata d'occhio alle sue capacità o, volendo, a una supposta mancanza delle stesse. 

La storia dei VCS

I sistemi di controllo di versione esistono da prima sia di Git che di BitKeeper. Diamo una rapida occhiata a una linea temporale storica:

• 1972 - SCCS, il primo VCS, viene creato dai Bell Labs; assomiglia ben poco ai sistemi odierni.
• 1982 - Il sistema di controllo delle revisioni (RCS) viene sviluppato da un informatico della Purdue University.
• 1986 - Viene sviluppato il Concurrent Versions System (CVS). È il primo VCS a offrire un repository centralizzato accessibile da più utenti.
• 1995 - Viene sviluppato Perforce, un VCS ancora oggi popolare.
• 2000 - Entra in scena un sistema più sofisticato chiamato Subversion (talvolta chiamato SVN). Così come BitKeeper, uno dei primi dVCS e quello che ha reso popolari i sistemi distribuiti.
• 2005 - Viene inventato Git, che diventa rapidamente la scelta di riferimento per gli sviluppatori di tutto il mondo. 

Git e GitHub, controllo di versione e repository

Git e GitHub sono tecnologie complementari. Git è un sistema di controllo di versione mentre GitHub è un servizio di hosting cloud che aiuta i team a gestire i loro repository. 

GitHub è stato progettato nel 2008 per rendere più semplice la programmazione collaborativa con Git, qualcosa in cui la piattaforma software as a service (SaaS) ha eccelso, attirando alla fine milioni di utenti in tutto il mondo. 

Oltre a offrire le funzionalità standard di controllo di versione di Git, GitHub ha funzionalità proprie come il tracciamento dei bug, strumenti di gestione delle attività e integrazione continua (CI). GitHub adotta un modello freemium: gli utenti possono accedere gratuitamente a molte funzionalità ma devono pagare un abbonamento premium per sbloccarle tutte. Dal 2018 GitHub è di proprietà di Microsoft. 

GitHub non è l'unico servizio di hosting di repository, ma con milioni di utenti e centinaia di milioni di progetti che si affidano alla piattaforma, è senza dubbio il più popolare al mondo. Su GitHub puoi trovare molte aziende di primo piano, tra cui DataCamp. 

Tra i servizi concorrenti ci sono GitLab, un servizio completamente gratuito e open source progettato per Git, e Bitbucket, che supporta sia la gestione del codice con Git che con Mercurial.

Abbiamo detto prima che Git e il controllo di versione non sono solo per il coding e lo sviluppo software; lo stesso vale per GitHub, anche se quest'ultimo non è ottimizzato per progetti non legati al codice.

Git è più di uno strumento per lo sviluppo software

Git può essere usato per qualsiasi progetto collaborativo in cui il controllo di versione conta, per esempio la stesura di un ampio manuale utente o persino la creazione di musica liturgica (quest'ultimo è un progetto reale che puoi vedere su GitHub)

Qui a DataCamp insegniamo gli strumenti e le tecnologie necessari per lavorare con i dati, incluso Git. La nostra gamma di corsi Git immersivi e coinvolgenti è disponibile qui.

Perché Git è così popolare?

Git è popolare per diversi motivi, non ultimo perché è gratuito e open source.

• Velocità. Git è veloce, soprattutto se consideriamo che gli sviluppatori creano branch e fanno merge di un intero repository. Poiché ogni persona del team ha la propria copia locale, non c'è bisogno di aspettare che ogni piccola modifica venga inviata a un server.
• Tracciamento minuzioso delle modifiche. Git offre un versioning incredibilmente dettagliato: anche le modifiche più piccole vengono registrate, e gli sviluppatori possono lasciare un commento con marca temporale per spiegare perché hanno apportato ogni modifica.
• Lavoro offline. Con copie locali dell'intero repository, gli utenti non devono essere online fino a quando non sono pronti a inviare le loro modifiche. 
• Ubiquità. Oggi Git è così comunemente usato che la sua ubiquità ne alimenta ulteriormente la popolarità. Oltre il 90% degli sviluppatori usa Git, e c'è poco motivo per un'azienda di utilizzare un altro strumento se sa che tutti gli sviluppatori conoscono Git.
• Collaborazione. Git abilita il lavoro collaborativo e rende semplice fondere versioni diverse dello stesso progetto, riducendo al minimo il rischio di conflitti. Con l'aggiunta di GitHub, gli sviluppatori dispongono di un ecosistema agile per il coding collaborativo che supporta il loro lavoro.

Come funziona Git?

Per comprendere davvero la potenza e l'efficienza di Git, dobbiamo approfondirne alcune complessità tecniche. Ecco una panoramica di come opera Git:

1. Repository (Repo). Un repository Git è una directory in cui sono archiviati tutti i file di un determinato progetto. Contiene tutte le revisioni e la cronologia del progetto. Quando inizializzi Git in una directory (git init), questa diventa un repository.
2. Commit. Ogni modifica o insieme di modifiche che finalizzi in Git è chiamato commit. Ogni commit ha un ID univoco (un hash SHA-1) che consente a Git di tenere traccia delle modifiche e dell'ordine in cui sono state apportate.
3. Staging area. Prima di finalizzare le modifiche con un commit, le "metti in stage". L'area di staging è come uno spazio di bozza in cui prepari le modifiche prima di effettuare il commit. Per aggiungere file all'area di staging usi il comando git add
4. Branch. Git ti consente di creare più linee di sviluppo usando i branch. Il branch predefinito si chiama master. Quando vuoi sviluppare una funzionalità o correggere un bug, puoi creare un nuovo branch (git branch <branch-name>) per isolare le modifiche senza toccare la linea principale di sviluppo.
5. Merge. Una volta terminato il lavoro su un branch, puoi unire quelle modifiche nel branch master (o in un altro branch) usando il comando git merge.
6. Repository remoti. Mentre lavori in locale sulla tua macchina, Git ti consente anche di connetterti a repository remoti usando il comando git remote. Questo è particolarmente utile per la collaborazione. Come detto, il repository remoto più comune è GitHub.
7. Push e pull. Una volta connesso a un repository remoto, puoi effettuare il push delle tue modifiche, permettendo ad altri di vedere e collaborare al tuo codice. Allo stesso modo, puoi effettuare il pull delle modifiche da un repository remoto per aggiornare la tua versione locale con gli ultimi aggiornamenti.
8. Fetch. Simile a pull, il comando git fetch ti consente di recuperare aggiornamenti da un repository remoto, ma non unisce automaticamente le modifiche nel tuo branch corrente. Questo ti dà la flessibilità di rivedere le modifiche prima di integrarle.
9. Clone. Se vuoi avere una copia di un repository Git esistente, usi il comando git clone. Questo crea una nuova directory sulla tua macchina con tutti i file e la cronologia del repository.
10. Risoluzione dei conflitti. A volte, quando più persone lavorano sulla stessa porzione di codice, possono sorgere conflitti. Git ha meccanismi integrati per evidenziare questi conflitti, consentendo agli sviluppatori di risolverli manualmente prima di finalizzare un merge.
11. Log. Per visualizzare la cronologia dei commit, Git fornisce il comando git log. Questo mostra un elenco di commit, i loro ID univoci e i messaggi associati.

Comprendere questi dettagli tecnici fornisce le basi per lavorare con Git. Man mano che ti familiarizzi con questi concetti e comandi, apprezzerai la flessibilità, la potenza e l'efficienza che Git porta nel controllo di versione.

Vuoi partire col piede giusto con Git?

Git è il VCS distribuito più popolare al mondo e ha rivoluzionato il modo in cui gli sviluppatori software e chi lavora in ambiti correlati gestiscono i propri progetti.

Aziende da Google a Netflix e molte altre usano Git come parte standard del loro stack tecnologico. L'ubiquità di Git è così pronunciata che, per qualsiasi progetto legato a software o codice, si può dare per scontato che Git faccia parte del processo. 

È anche un'abilità imprescindibile per chi lavora con i dati, come analisti e data scientist. Dopotutto, abbiamo bisogno di un modo per versionare il codice che ci aiuta a gestire i dati per ottenere insight e a costruire strumenti software che supportano il nostro lavoro.

Git è lo standard de facto dei VCS e, se vuoi lavorare nell'IT o in un settore adiacente, è un'abilità indispensabile. Sebbene Git non sia esattamente noto per la sua semplicità, è abbastanza facile padroneggiarne le basi e costruire le tue conoscenze man mano che progredisci nel Gitverse. 

DataCamp può aiutarti. Il nostro corso Introduction to Git è pensato per insegnarti l'essenziale di Git in modo divertente e coinvolgente. Una volta che avrai preso il ritmo, potresti pensare di ottenere la certificazione GitHub per mostrare le tue competenze. 

Per scoprire perché oltre nove milioni di learner in tutto il mondo amano DataCamp, iscriviti oggi al tuo primo corso su Git!