Git - git modelli di branching

Git Merge Vs Rebase

Nello sviluppo collaborativo con Git il merge ed il rebase sono fondamentali per la gestione dei workflow.  Spesso però si fa un pò di confusione: meglio utilizzare merge o rebase? Nei vari manuali di Git, il rebase viene sempre descritto come un comando da non utilizzare, soprattutto quando non si è ancora presa dimestichezza con l’ambiente. In realtà, in molti casi può essere uno strumento molto utile per lo sviluppo collaborativo.

Analizzando il comportamento dei due comandi possiamo affermare che entrambi consentono di integrare le modifiche da un ramo all’altro. La differenza sostanziale, è come lo fanno.

Creando un nuovo branch, e producendo una serie di commit, la situazione che si viene a creare potrebbe essere simile a quella descritta nella figura sottostante:

branch

Il ramo Feature è avanzato rispetto allo sviluppo di master. Si rende necessario allineare il flusso di lavoro di master a quello di feature. Utilizzando merge, è possibile unire il ramo master con le implementazioni che sono state effettuate nel ramo feature. I comandi da impartire sono:

Come si può notare il comando consente di posizionarsi sul ramo feature e di ricervere le commit presenti in master. Questo tipo di operazione non è invasiva sulla struttura pre-esistente dei rami.

merge

Nel caso in cui le attività su master siano molto “compulsive”, il flusso di sviluppo potrebbe risultare di non semplice interpretazione per gli altri sviluppatori del team. Questo perchè sarebbero necessari numerosi merge per poter allineare feature.

La seconda strada è quella di utilizzare rebase. Attenzione: rebase riscrivere l’intera cronologia dei commit.

Dopo essersi posizionato sul ramo feature, il comando rebase accoda l’intero ramo feature a master, producendo la seguente situazione:

rebase

E’ evidente come il rebase porta alla creazione di un flusso di lavoro molto più lineare, rispetto all’utilizzo di merge, eliminando tutta la cronologia di commit sviluppata nel ramo feature. Ma cosa è successo per il flusso collaborativo? Potrebbero verificarsi danni irreversibili: si perde, in pratica, lo storico delle modifiche che sono avvenute prima dell’operazione di rebase.

Quando non fare rebasing?

La domanda da porsi prima di fare il rebase è: “qualcun altro membro del team sta lavorando su questo branch?“. Se la risposta è SI, è necessario valutare accuratamente altre soluzioni per effettuare il merge (o il discard delle modifiche). Il motivo è piuttosto semplice, modificando il puntatore corrente, ad esempio sul branch pubblico master, tutti gli altri sviluppatori si troverebbero in una situazione non molto chiara e soprattutto semplice da gestire. Mentre gli altri sviluppatori stanno ancora lavorando sul ramo master originale, dopo aver eseguito il comando rebase il nostro ramo si troverebbe con le modifiche presenti in master accodate al nostro branch corrente: i due master saranno completamente disallineati.

Rebase con MasterLa regola fondamentale del rebase: Mai eseguire un rebase su rami pubblici. 

Documentazione ufficiale di rebase

Pubblicato da

Andrea Merlin

Laureato in informatica, diversi corsi di specializzazione legati allo Sviluppo Software e alla Computer forensics. Appassionato di nuove tecnologie, amo la programmazione, la Business Intelligence e tematiche legate alla Privacy.Sempre alla ricerca di nuove idee, stimoli … e progetti da seguire!Amo trascorrere il tempo libero in Val Borbera, un piccolo angolo del Piemonte, in provincia di Alessandria.