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

Annuncio pubblicitario

Come sviluppatori web, per la maggior parte del tempo tendiamo a lavorare su siti di sviluppo locali per poi 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, semplicemente no fattibile. Questo è quando passiamo a qualcosa chiamato controllo della versione.

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

Perché usare il software di controllo versione?

Innanzitutto, il nome dovrebbe darlo via. Il software di controllo versione consente di disporre di "versioni" di un progetto, che mostrano le modifiche apportate al codice nel tempo e consente di tornare indietro se necessario e annullare tali modifiche. Questa capacità da sola - di poter confrontare due versioni o invertire le modifiche, la rende abbastanza preziosa quando si lavora su progetti più grandi.

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

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

I vantaggi di un sistema come questo è che più sviluppatori possono apportare modifiche e ogni modifica può quindi essere attribuita a uno sviluppatore specifico. Sul lato negativo, il fatto che tutto sia archiviato in un database remoto significa che non è possibile apportare modifiche quando il server si arresta; 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 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 utilizzato, ma se dovesse accadere il peggio, allora tutto può ancora essere ripristinato da uno qualsiasi dei client che dispongono delle versioni più recenti.

Git funziona specificamente prendendo "istantanee" di file; se i file rimangono invariati in una particolare versione, si collega semplicemente ai file precedenti, mantenendo tutto veloce e snello.

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

Che cos'è Github?

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

Forking & Branching

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

Probabilmente hai sentito il lavoro "fork" quando hai a che fare con le 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 bellissimo e personalizzabile per XBMCConfigura il tuo media center esattamente come lo desideri. Aeon Nox 3.5 è la versione più recente di quello che è forse il miglior tema per XBMC, ed è una combinazione rara: bella ... Leggi di più . Questo significa semplicemente che ad un certo punto in passato alcuni sviluppatori hanno preso il codice di XBMC e hanno deciso di seguirlo a modo loro; che divenne Plex.

Questo è ovviamente 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 poter essere ripristinati nel progetto "master", tu può fare una "richiesta pull" all'autore, chiedendo loro di riportare le modifiche nel loro originale progetto. Ciò ti 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: copiano semplicemente il codice, apportano modifiche e richiedono di eseguire il rollback nel file maestro. Naturalmente, spetta al proprietario del progetto originale se decide di accettare le modifiche o meno.

Il branching è qualcosa fatto internamente su un progetto dagli sviluppatori autorizzati. Ti consente di separare facilmente problemi o funzionalità specifici e di lavorarci su senza rompere i file master. Una volta che sei soddisfatto del fatto che la tua filiale abbia risolto il problema, lo ricolleghi al master. In qualsiasi momento, ci possono essere tutti i rami che vuoi; non interferiscono l'uno con l'altro. Puoi anche unire le modifiche tra i rami senza toccare il master.

Ecco un ottimo 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 la panoramica più breve qui, ma come sviluppatore che è abituato a fare modifiche e a annullarle se non funzionano, l'intero concetto mi ha fatto impazzire - spero che lo 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!