Controllo di versione e merging
Uno dei vantaggi derivanti dal versioning riguarda la possibilità di operare sui vari stadi evolutivi di un progetto indipendentemente dallo status associato all'ultima istantanea disponibile sul relativo repository. A questo proposito si ipotizzi di essere impegnati nello sviluppo di un'applicazione, quest'ultima potrebbe essere in fase avanzata di implementazione e aver già raggiunto la versione stabile 1.0. Volendo introdurre ulteriori funzionalità, magari degne di una nuova major release, potrebbe rivelarsi opportuno creare un nuovo ramo, ad esempio il 2.x.
A questo punto il ramo 1.x non verrà necessariamente abbandonato, anzi, essendo plausibilmente il branch di produzione principale in attesa che la versione 2.0 diventi definitiva, esso continuerà a ricevere supporto. Questo significa che anche nel caso in cui si stia lavorando sul nuovo ramo sarà sempre possibile intervenire su quello precedente nel caso in cui emergano delle problematiche a suo carico.
Potrebbe per esempio accadere che un utilizzatore della release 1.x invii un feedback segnalando l'individuazione di una vulnerabilità o di un malfunzionamento; ricevuta tale notifica gli sviluppatori potranno riprendere in mano la versione buggata, generare un nuovo ramo contenente la correzione del problema rilevato e unire quest'ultimo con quello da correggere per poi tornare a lavorare sul ramo 2.x.
La procedura che prevede l'apertura di un nuovo ramo per l'esecuzione di un intervento e la sua successiva fusione con il ramo che presenta la necessità di un aggiornamento prende il nome di merging, letteralmente "fusione".
Creazione di un ramo per interventi di manutenzione
Al fine di proporre un esempio pratico delle operazioni precedentemente descritte è possibile fare riferimento ad un caso specifico; l'immagine proposta di seguito riassume le fasi di implementazione e commit di una Web application fino al raggiungimento della prima versione definitiva:
A questo punto la release 1.0 potrà andare in produzione e gli utilizzatori avranno la possibilità di inviare eventuali segnalazioni riguardanti i bug rilevati in fase di esecuzione. I feedback ricevuti dagli sviluppatori potrebbero essere più o meno rilevanti e necessitare o meno interventi immediati, si immagini quindi di ricevere la segnalazione "fbk-4" riguardante una problematica da risolvere nel più breve tempo possibile.
Per la creazione di un nuovo ramo finalizzato al necessario intervento di manutenzione sarà possibile utilizzare un'istruzione basata sul comando git checkout seguito dall'opzione -b e da nome del branch addizionale:
Per completezza, è bene precisare che sarebbe stato possibile ottenere lo stesso risultato digitando le seguenti istruzioni:
$ git branch fbk-4
$ git checkout fbk-4Che si scelga la sintassi abbreviata o quella completa, l'utilizzatore vedrà il suo piano di lavoro redirezionato sul nuovo ramo grazie al riposizionamento del puntatore HEAD, ciò significa che in mancanza di uno spostamento sul ramo di produzione originario tutti i commit che verranno eseguiti successivamente avranno effetto sul branch più recente.
Ora si ipotizzi la ricezione di un'ulteriore segnalazione riguardante, ad esempio, la presenza di una vulnerabilità nel ramo di produzione; anche in questo caso l'intervento dovrà avvenire nell'immediato per necessità correlate alla sicurezza. I cambiamenti apportati per la risoluzione della criticità precedentemente esposta non andranno perduti, così come rimarrà disponibile il ramo di manutenzione creato per la sua risoluzione.
L'ultimo intervento richiesto potrà essere risolto riposizionando il puntatore verso il ramo master tramite l'istruzione git checkout master.
Una volta avvenuto il riposizionamento lo sviluppatore potrà operare su una directory di lavoro identica a quella memorizzata prima dell'intervento eseguito per la segnalazione "fbk-4", sostanzialmente dopo il checkout verrà nuovamente offerto lo snapshot associato al commit più recente a carico del master. Ciò avverrà, cioè sarà consentito dal DVCS, ad una condizione, e cioè che le modifiche apportate al progetto nella working directory o nell'area di stage non presentino dei conflitti con il ramo verso il quale si vuole redirezionare il puntatore.
Il merging
Una volta raggiunto il ramo master, si potrà utilizzare quest'ultimo come base per lavorare alla risoluzione della vulnerabilità segnalata partendo dalla generazione di un apposito branch, denominato "vuln-1" nel nostro esempio, su cui riposizionare per l'ennesima volta il puntatore.
Effettuato l'intervento correttivo a carico della vulnerabilità da eliminare si potrà procedere con il relativo commit rimanendo sul nuovo ramo:
Dato che la vulnerabilità è stata eliminata non avremo più bisogno del ramo "vuln-1" e potremo ricorrere al merging per fonderlo con il master; riposizioneremo quindi il puntatore su quest'ultimo e utilizzeremo l'istruzione git merge seguita dal nome del branch che vogliamo unire al master.
Fatto questo il mantenimento del ramo "vuln-1" diverrà del tutto inutile e lo si potrà eliminare definitivamente ricorrendo all'istruzione git branch -d vuln-1.
Il ramo di manutenzione "fbk-4", che non è stato coinvolto in alcun merging o cancellato, continuerà quindi ad essere disponibile per ulteriori interventi fino a quando lo sviluppare riterrà necessario mantenerlo, ad esempio in attesa che l'utente che aveva effettuato la segnalazione abbia approvato la modifica conseguente al proprio feedback.
