Quando usare git rebase? In questo articolo ho il piacere di aiutarti a capire quando usare il rebase nei tuoi repository git.
Git come sistema di version control ci offre parecchia, ma parecchia roba! Per “roba” non intendo quella roba, ma al contrario intendo la miriade di comandi e possibili variazioni che ci offre per gestire i nostri repository!
E parlando di come gestire i nostri repository, se sei qui è perchè vuoi capire quando usare git rebase all’interno del tuo progetto: non temere, ci arriviamo a breve, ma prima le presentazioni!
Mi chiamo Lorenzo Neri e sono un informatico: articoli come questo nascono dai problemi che ho avuto nel corso della mia carriera lavorativa a cui ho cercato di apporre una soluzione. Quale miglior modo se non realizzare articoli come questo che stai leggendo?
Iniziamo.
Quando usare git rebase?
Il rebase come comando in sé, permette di riadattare la storia di un ramo e posticiparla: in che senso?
Facciamo un esempio partendo da questa situazione:
Vorremmo portarci nella seguente:
Ti sento già, e avresti ragione a dirlo!
“Lorenzo ma perché non fare un merge?” sarebbe una domanda più che lecita!
Come puoi vedere dall’esempio, il rebase fa sì che la storia del branch, in questo caso quello nominato “fix256”, venga ri-posizionata e dunque fa sì che la sua partenza venga accomunata al commit più recente del branch base.
Da un punto di vista del contenuto effettivo della codebase, è quello che otterresti facendo un merge: uniamo i cambiamenti e buonanotte al secchio!
Eh, mica tanto: nel caso di un merge le storie dei due rami rimarrebbero separate:
Dunque se ti stai chiedendo quando dovresti usare git rebase, lo scenario più comune è il seguente: stai lavorando a delle tue modifiche a un progetto, ma un tuo collega ha realizzato delle modifiche consistenti su un altro branch. La cosa più pratica è letteralmente prendere quelle modifiche e metterle in testa al branch su cui stai lavorando tu. In questo modo avrai una storia nel tuo repository molto più pulita e leggibile.
Un’altro caso in cui è bene usare git rebase è quello in cui ci sono veramente troppi merge inutili che aggiungono complessità alla storia del tuo repository. Per intenderci e farla breve, se un merge legato ad una determinata feature in fase di sviluppo (quindi non un branch principale) necessita parecchi merge per includere parti importanti dei branch principali, ti ritroverai ad avere più commit che consistono in un merge nudo e crudo piuttosto che avere commit veri e propri di contenuti apportati alla codebase.
Molto meglio eseguire un rebase di questo branch e dunque accordarlo, anzi posticiparlo nella storia, con un rebase.
Eppure, nonostante ci siano aspetti positivi nell’usare il rebase, ti pare che non ce ne siano di negativi?
I contro di tutto questo
Una volta capito quando usare git rebase, è giusto capire quali aspetti negativi porta con sé.
Il primo fra tutti, è che siccome sposta letteralmente l’andamento storico dei branch porta ad avere date ed orari sfalzati: per farla breve i commit che verranno spostati avranno la data e l’orario del momento in cui viene eseguito il rebase! Questo diciamo è il primo motivo per preferire i merge al rebase, ma non è l’unica cosa: eh no!
Ci sarebbe un’intera categoria di articoli su git che puoi trovare qui sul blog (pssst! È in quel link qualche parola fa, scoprila!), ma limitiamoci al secondo contro di usare git rebase.
Per fartela breve, se il branch che subirà il rebase ha più di un singolo commit che modificano una linea di codice e, quella stessa linea di codice viene modificata nel branch base, beh… Preparati ad avere non pochi conflitti da risolvere.
E parlando di conflitti da risolvere su git, ti invito a scoprire qualcosa a riguardo proprio qui 😉
