Se anche voi ne avete già sentito parlare ma non sapete di cosa tratta, continuate la lettura.
Se anche voi pensate che come quasi ogni argomento dello sviluppo software anche questo sia un ennesimo acronimo, continuate la lettura.
Un po’ di doverosa e noiosa teoria per iniziare:
Git è un software nato nel 2005 grazie all’immenso genio contenuto in quei pochi Kg (ora forse non più così pochi) che compongono Linus Torvalds (tra le altre cose padre fondatore del sistema operativo più in uso al mondo sui server, ndr), con l’obiettivo di semplificare il versionamento del codice.
E sì, il nome deriva proprio dalla parola “incompetente” in uso nello slang americano.
Dalla folla sento:
“Perchè è così importante?”
“Che ci frega di versionare?”
“Non possiamo farne a meno?”
“Dobbiamo complicarci la vita ad imparare un altro software, per fare software?”
E da qui questi prossimi paragrafi semi-seri in cui appariranno, in ordine sparso, lettere rovesciate, viaggi del tempo, ricette di cucina tradizionale, automobilisti scriteriati ed un gentile contributo dei Limp Bizkit.
In buona sostanza direi di sì, è davvero così importante, e altrettanto sì, sarebbe meglio evitare di vivere senza, perchè permette un ottimo controllo di tutte le modifiche che vengono fatte all’applicazione nel corso del suo ciclo di vita.
Come un po’ in tutto quel che esiste al mondo però la virtù sta nel mezzo, quindi è anche importante valutare quando davvero abbia senso utilizzarlo in modo approfondito e quando invece per quelle che possiamo definire le sue funzioni più “base”.
Per spiegare uno dei problemi che git risolve utilizzo spesso questo esempio: nel mondo odierno, quello delle rotonde, i piloti urbani vengono chiamati a spremere i propri neuroni per capire quando sia arrivato il momento di immettersi nel caotico flusso di traffico.
Nello sviluppo software non possiamo però pensare che ogni attore in gioco possa autonomamente arrangiarsi e decidere di iniettare in rotonda il proprio codice solo perchè c’è un buco libero e secondo me ci passo.
Dobbiamo quindi tornare ai tempi dei semafori, o meglio ancora dei vigili, così umanizziamo un po’ la cosa, dato che il settore IT soffre di un ingiusto appeal sempre così troppo cibernetico.
Esci come ogni mattina per andare al lavoro, arrivi all’incrocio e ti fermi, il buon vigile ti ha indicato che non è il momento, ora.
Attendi qualche istante e tra una controllata allo smartphone (o non è coevo?) e una al retrovisore - sostituire se siete single con bionda, mora, rossa o quel che si desidera - ed ecco che il tutore della legge ti fa cenno di proseguire.
Hai dato il tuo contributo al traffico senza causare danni, stellina in arrivo.
Git fa più o meno la stessa parte del vigile, ma essendo un software lo fa in modo molto più veloce, immediato direi, al punto che non ti accorgi di esserti fermato. Strabiliante.
Veniamo ora alla parte davvero cruciale, lo scampato incidente, il vero effetto wow di tutta sta cosa.
Si perchè alla fine il motivo è quello, evitare di scontrarsi con gli altri ed agli incroci è un attimo, si sa.
Passo io, passi tu, sbam…
E poi mezz’ora sotto la pioggia con il modulo della constatazione amichevole, il capo che ti chiama mille volte e break stuff in testa.
Noi che non bramiamo dal bisogno di dar da mangiare alle compagnie assicurative saremmo quindi ben lieti di riuscire a raggiungere sempre indenni la nostra destinazione.
Torniamo allora alle diatribe tra noi e il nostro computer, la metafora credo sia arrivata.
Mettiamo che stiamo lavorando in due su un progetto, non perchè sia complesso, ma perchè siamo pigri.
Quando si lavora in più di una persona, o meglio, soprattutto quando si lavora in più di una persona, si tende a fare in questo modo: ognuno implementa i propri sviluppi nella propria versione locale del progetto per poi rilasciare il tutto in produzione, ovvero l’ambiente ufficiale da cui sarà possibile fruire l’applicazione pubblicamente.
Mettiamo che in un dato momento faccio nella mia versione in locale una modifica ad un file preesistente, ad esempio aggiungo un’immagine in un file html, e allo stesso modo anche il mio compare di merende fa modifiche allo stesso file, nella sua versione in locale, magari aggiunge un testo.
In quel momento esistono quindi 2 versioni di quel file:
- la mia con il pregresso + l’immagine
- la sua con il pregresso + il testo
Se alle 17:30 carico la mia versione del file in produzione perchè disturbato durante la sacrosanta pennichella delle 14-18 accade che non appena il collega si sveglia dalla botta di amatriciana e carica alle 18:10 la sua, mi sovrascriverà: la mia aggiunta dell’immagine verrà persa ed esisterà solo la sua versione, con la sola aggiunta del testo. Eppure io ero arrivato uno… Molta rabbia.
Questo accade perchè il suo file non conteneva le mie modifiche, conteneva solo le sue, i nostri due file non sono stati fusi insieme prima del rilascio e lui mi ha sovrascritto, polverizzando il mio faticosissimo lavoro.
Detta così è banale, che ci vuole, basta che prima di pubblicare ci si dia una gomitata e ci si confronti...
Immaginiamo però quando non siamo pigri e ognuno di noi esegue 1.000 modifiche, distribuite su 100 file diversi, e non siamo in due ma in 40...
Sentite anche voi il bisogno di quel vigile ora, vero?!
Chi già utilizza sistemi collaborativi per il project management o anche banalmente Google Drive/Office 365 ha già capito il concetto, proprio perchè alla base di tutti questi strumenti vi è un software di versionamento, che peraltro probabilmente è facile sia proprio git...
Pensiamo al workflow di git come ad una Y rovesciata, sottosopra:
. le 2 modifiche vengono salvate in locale (commit)
. e le facciamo confluire (push) in un unico punto, ovvero la repo git
. nel punto di incontro avviene la magia, la fusione dei contributi (merge). Esisterà quindi un nuovo file che contiene tutte le modifiche di tutti
. questo file verrà poi sincronizzato in locale (pull) ed utilizzato da tutti per essere sempre allineati alle più recenti variazioni
. il contenuto della repo viene rilasciato (deploy) e reso disponibile per qualsiasi altra attività (il download di una patch, l'aggiornamento su un server esterno di nuove funzionalità ecc.ecc.)
Appunto, una Y rovesciata...
In quanto sistema di versionamento, parola chiave nell’ecosistema git, il software tiene traccia di tutto quello che sia mai stato fatto nella repository: la data delle modifiche, i file che sono stati modificati, chi ha operato tali modifiche, le condizioni meteo di quel giorno e via dicendo. Questo consente qualcosa di molto importante, quando le cose vanno storte, quando non dai retta al vigile, ovvero poter tornare indietro nel tempo a quando la tua auto non era ancora mezza distrutta in quel maledetto incrocio. Visibilio.
Del resto anche il flusso canalizzatore della DeLorean è proprio a forma di Y, tutto torna...
Quindi, per concludere questa prima parte (eh sì, mica pensavate fosse tutto finito qui!) possiamo riassumere gli obiettivi di git in:
- tenere traccia di tutte le modifiche fatte da ognuno dei collaboratori, per poter tornare indietro, attribuire colpe ecc.
- fondere i contributi di ognuno dei collaboratori, per riuscire a terminare velocemente e farsi pagare
- disporre di codice sempre aggiornato, condiviso e rilasciabile ovunque sia necessario, metti che ti rubano il pc!
