Che cos'è Git e perché dovresti usare il controllo della versione se sei uno sviluppatore

Come sviluppatori web, molte volte tendiamo a lavorare su siti di sviluppo locali, quindi basta caricare tutto quando abbiamo finito. Questo va bene quando sei solo tu e le modifiche sono piccole, ma quando hai a che fare con più di una persona che lavora su qualcosa, o su un grande progetto con molti componenti complicati, non è fattibile. È qui che ci rivolgiamo a qualcosa chiamato controllo della versione.

Oggi parlerò di un software di controllo della versione open source chiamato Git. Ciò consente a più persone di lavorare in sicurezza sullo stesso progetto senza interferire tra loro, ma è molto più di questo.

Perché utilizzare il software di controllo della versione?

Prima di tutto, il nome dovrebbe darlo via. Il software di controllo della versione ti consente di avere “versioni” di un progetto, che mostra le modifiche apportate al codice nel tempo e consente di tornare indietro se necessario e annullare tali modifiche. Questa capacità da sola - di essere in grado di confrontare due versioni o di invertire le modifiche, lo rende piuttosto prezioso quando si lavora su progetti più grandi.

Probabilmente lo hai già fatto da solo a un certo punto, salvando le copie di un progetto in diversi punti in modo da avere un backup. In un sistema di controllo della versione, sarebbero state salvate solo le modifiche: un file patch che poteva essere applicato a una versione, in modo da renderlo uguale alla versione successiva. Con uno sviluppatore, questo è sufficiente.

Ma cosa succede se hai più di uno sviluppatore che lavora su un progetto? È qui che entra in gioco l'idea di un server di controllo della versione centralizzato. Questi sono stati lo standard per molto tempo, in cui tutte le versioni sono archiviate su un server centrale e i singoli sviluppatori eseguono il checkout e caricano le modifiche su questo server. Se hai mai guardato la cronologia delle modifiche di una pagina di Wikipedia, avrai una buona idea di come funzioni in uno scenario reale:

I vantaggi di un sistema come questo sono che più sviluppatori possono apportare modifiche e ogni modifica può quindi essere attribuita a uno sviluppatore specifico. Al rovescio della medaglia, il fatto che tutto sia archiviato su un database remoto significa che non è possibile apportare modifiche quando il server non funziona; e se il database centrale viene perso, ogni client ha solo la versione corrente di qualunque cosa stessero lavorando.

Questo ci porta a Git e ad altri cosiddetti sistemi di controllo della versione distribuiti. In questi sistemi, i client non controllano solo la versione corrente dei file e lavorano da essi, ma rispecchiano l'intera cronologia delle versioni. Ogni sviluppatore ha sempre una copia completa di tutto. Un server centrale è ancora usato, ma nel caso peggiore, tutto può ancora essere ripristinato da uno qualsiasi dei client che hanno le ultime versioni.

Git funziona specificamente prendendo “istantanee” di file; se i file rimangono invariati in una particolare versione, si collegano semplicemente ai file precedenti - questo mantiene tutto veloce e snello.

Potrebbe anche interessarti sapere che Git è usato per gestire e sviluppare il kernel di linux core - il blocco base su cui sono costruite tutte le distribuzioni di Linux.

Cos'è Github?

Sebbene sia possibile eseguire il proprio server Git localmente, Github è sia un server remoto, una comunità di sviluppatori, sia un'interfaccia grafica per la gestione del proprio progetto Git. È gratuito da utilizzare per un massimo di 5 repository pubblici, ovvero quando chiunque può visualizzare o imporre il proprio codice, con piani a basso costo per progetti privati. Ti consiglio vivamente di iscriverti a un account gratuito in modo da poter iniziare a giocare con i tuoi progetti o biforcarsi a qualcuno.

Forking e ramificazione

Questi sono concetti chiave dell'esperienza Git, quindi prendiamoci un momento per spiegare la differenza.

Probabilmente hai sentito il lavoro “forchetta” quando si tratta di distribuzioni di Linux. Se hai familiarità con l'app media center Plex, saprai che in origine era un fork del simile open source Xbox Media Center Aeon Nox 3.5: Tema bello e personalizzabile per XBMC Aeon Nox 3.5: Tema bello e personalizzabile per XBMC Set il tuo media center esattamente come lo vuoi tu. Aeon Nox 3.5 è la versione più recente di quello che è forse il tema migliore per XBMC, ed è una combinazione rara: bella ... Per saperne di più. Ciò significa semplicemente che, ad un certo punto del passato, alcuni sviluppatori hanno preso il codice di XBMC e hanno deciso di seguire la propria strada con esso; è diventato Plex.

Questo è ovviamente totalmente consentito quando il progetto è open source: puoi prendere il codice, fare quello che vuoi con esso. Con Git, se ritieni che i tuoi cambiamenti siano abbastanza buoni da essere riportati indietro nel “maestro” progetto, puoi fare un “richiesta di pull” all'autore, chiedendo loro di ritirare le modifiche nel loro progetto originale. Ciò consente di avere centinaia di migliaia di sviluppatori che lavorano su un progetto in qualsiasi momento, nessuno dei quali deve essere necessariamente approvato per l'accesso al codice: copia semplicemente il codice, apporta modifiche e richiede di essere reinserito nel master. Naturalmente, spetta al proprietario del progetto originale se decide di accettare o meno le modifiche.

Branching è qualcosa fatto internamente su un progetto dagli sviluppatori autorizzati. Ti consente di separare facilmente problemi o funzionalità specifici e di lavorare su di essi senza rompere i file master. Una volta che sei soddisfatto che il tuo ramo ha risolto il problema, lo unisci nuovamente al master. In qualsiasi punto, ci possono essere tanti rami quanti ne vuoi; non interferiscono l'uno con l'altro. È anche possibile unire le modifiche tra i rami senza toccare il master.

Ecco un grande diagramma di un flusso di lavoro di esempio di Vincent Driessen:

La prossima volta vedremo come impostare un esempio Git funzionante e apportare modifiche al codice all'interno dei rami. Il controllo della versione è un argomento enorme. Ho dato solo una panoramica più breve qui, ma come sviluppatore abituato a fare solo modifiche e annullarle se non funzionano, l'intero concetto mi è saltato in mente - spero che faccia anche il tuo.

Sei uno sviluppatore esperto con esperienza in Git? Hai appena iniziato e pensi che ti piacerebbe provare? Audio disattivato nei commenti!

Scopri di più su: programmazione, gestione dei progetti, sviluppo web.