Visualizzazione dei rami
Parlando di ramificazioni abbiamo descritto l'utilizzo del comando git branch nei casi in cui si voglia creare un nuovo ramo o, al contrario, cancellare un ramo esistente. Lo stesso comando può essere utilizzato anche per eseguire delle semplici verifiche sui rami di un progetto, lanciato senza il passaggio di alcun parametro permette infatti di stampare a video una lista completa dei rami disponibili in un dato momento.
Nell'immagine proposta vengono elencati due rami, quello master, creato dal sistema, e "fbk-4", generato per effettuare un intervento di manutenzione. Non viene giustamente elencato il ramo "vuln-1", creato per la risoluzione di una problematica di sicurezza; infatti, una volta corretta la vulnerabilità che lo ha reso necessario, esso è stato prima fuso con il master e poi eliminato perché non più necessario.
Facendo attenzione al modo in cui viene presentato l'output di git branch è possibile notare che il nome del ramo master è preceduto da un asterisco ("*"), questo simbolo viene utilizzato da Git per indicare all'utilizzatore il ramo corrente, cioè quello in cui egli si trova attualmente e verso il quale è rivolto il puntatore dei rami. L'asterisco funziona in sostanza come indicatore per capire in quale posizione ci troviamo rispetto al nostro piano di lavoro.
Stato delle fusioni
Un altro utilizzo di git branch riguarda la possibilità di visualizzare i rami che sono stati sottoposti a merging e quelli che invece non hanno subito una fusione. Per mostrare il funzionamento di questa procedura è possibile partire dalla creazione di un nuovo ramo ("fbk-5" nell'esempio) e dal riposizionamento del puntatore su di esso:
Fatto questo operiamo una modifica a carico di un file del progetto e, dopo averla salvata, aggiungiamola all'Index e validiamola tramite un commit:
Una volta confermate le modifiche possiamo passare al merging di "fbk-5" con il ramo master, quindi spostiamoci su quest'ultimo riposizionando il puntatore su di esso e lanciamo il comando git merge fbk-5.
Ora possiamo utilizzare l'istruzione git branch seguita dal parametro --merged per operare una verifica dei rami che hanno subito una fusione e non sono stati cancellati; l'opzione --no-merged consente al contrario di visualizzare i rami esistenti che non sono stati sottoposti a merging.
Come è possibile notare grazie all'immagine precedente, dall'elenco dei rami sottoposti a merging manca "vuln-1", esso infatti è stato fuso con il master per poi essere cancellato.
Sicurezza dei rami
Git integra delle funzionalità di controllo per evitare che l'utilizzatore perda il proprio lavoro, ecco perché i rami che non sono stati fusi non potranno essere cancellati con una normale procedura per la rimozione. Nel caso del nostro progetto abbiamo un unico ramo non fuso, "fbk-4", quindi per capire in che modo il DVCS protegge i rami non sottoposti a merging spostiamo il puntatore su di esso, effettuiamo una modifica a carico di un file, aggiungiamola all'indice tramite git add e lanciamo un commit per confermarla.
Ora riposizioniamo il puntatore sul ramo master in modo da operare a partire da esso e proviamo a cancellare "fbk-4".
Come evidenziato dall'immagine precedente, per la cancellazione di un ramo che non ha subito il merging non è sufficiente utilizzare la classica istruzione git branch -d nome-ramo, se si è assolutamente sicuri di voler procedere con la rimozione è invece prevista l'istruzione git branch -D nome-ramo.
Visualizzare i commit dei rami
Il comando git branch può essere associato all'argomento -v per ottenere informazioni riguardo agli ultimi commit effettuati. Lanciamo quindi questa istruzione a partire dal ramo master e analizziamo l'output prodotto da Git:
Il report prodotto è di facile lettura. I rami vengono disposti sulla base della cronologia dei commit a partire da quello eseguito più di recente, nel caso specifico del nostro progetto abbiamo quindi per primo il commit a carico del ramo "fbk-4", cioè quello che non è stato sottoposto a fusione. Seguono il ramo "fbk-5", per il quale abbiamo effettuato il merging con il master, e quest'ultimo.
Si noti come il commit del ramo "fbk-5" sia identico a quello del master, questo perché i due rami sono stati fusi e il master, non essendo stato coinvolto da ulteriori commit dopo la fusione con il nuovo ramo, lo ha ereditato da "fbk-5" come ultima convalida di un aggiornamento.