Git rebase: rias­se­gna­re i commit in cima a un altro branch

Git rebase integra le modifiche di un branch in un altro. Questo comando Git offre più opzioni rispetto a git merge, ma dovrebbe essere usato con cautela.

Una ca­rat­te­ri­sti­ca es­sen­zia­le del lavoro con Git è la pos­si­bi­li­tà di lavorare in team o da soli con­tem­po­ra­nea­men­te su diverse parti di un progetto, ap­por­tan­do modifiche, lavorando alla ri­so­lu­zio­ne dei problemi e mettendo infine il lavoro svolto a livello locale nuo­va­men­te a di­spo­si­zio­ne di tutti gli altri membri. Questo funziona da un lato grazie all’uso di re­po­si­to­ry locali e dall’altro, uno scalino più in basso, grazie all’impiego di ra­mi­fi­ca­zio­ni, anche chiamate branch. In questo modo potete apportare modifiche in modo autonomo, senza andare a influire sul resto del progetto. Se però volete integrare le modifiche eseguite su un branch in un altro branch, il sistema di controllo di versione vi offre due opzioni.

Git merge e git rebase sono entrambi utili per unire diversi elementi, ma pre­sen­ta­no anche delle chiare dif­fe­ren­ze. Fra le due opzioni, git rebase è con­si­de­ra­to la soluzione più elaborata. Questo comando Git serve a spostare una sequenza di commit in un nuovo commit di base. In questo modo un intero branch viene spostato in cima a un altro branch, mo­di­fi­can­do la base del commit. In altre parole, git rebase riscrive anche la cro­no­lo­gia del progetto, poiché vengono creati nuovi commit per ogni commit del branch originale. In questo contesto si distingue fra approccio manuale e in­te­rat­ti­vo.

Per poter com­pren­de­re come funziona realmente git rebase, può essere utile dare un’occhiata alla sintassi del comando, che è re­la­ti­va­men­te intuitiva. Nel seguente esempio ci spostiamo sul branch “nuovo” con git checkout, un comando che potete trovare anche nella nostra pratica guida “Git Cheat Sheet” sca­ri­ca­bi­le in PDF. Suc­ces­si­va­men­te in­te­gria­mo il branch “nuovo” nel master tramite git rebase. A questo scopo basta usare il relativo comando, nel quale non dobbiamo fare altro che spe­ci­fi­ca­re il branch di de­sti­na­zio­ne. Questo il codice:

In questo modo il branch “nuovo” viene rias­se­gna­to in cima al branch master e la cro­no­lo­gia del progetto viene riscritta.

L’esempio illustra l’uso standard di git rebase: il comando viene eseguito au­to­ma­ti­ca­men­te nel branch se­le­zio­na­to e applicato al branch HEAD (in questo caso “master”). Tutti i commit vengono spostati e assegnati in cima al nuovo branch. La variante in­te­rat­ti­va di git rebase offre ulteriori opzioni utili, con­sen­ten­do­vi di se­le­zio­na­re, mo­di­fi­ca­re, spostare o anche can­cel­la­re singoli commit. Questa opzione è utile se volete rior­di­na­re e in alcuni casi ot­ti­miz­za­re la cro­no­lo­gia come ritenete più opportuno. Il relativo comando è quasi uguale alla versione standard, con l’aggiunta di “-i”:

Quando eseguite questo comando, si apre au­to­ma­ti­ca­men­te un editor in cui viene vi­sua­liz­za­ta la lista di tutti i commit, che potrete mo­di­fi­ca­re a vostro piacere.

Per chi ha già una certa espe­rien­za, git rebase offre ulteriori opzioni utili. Queste le più im­por­tan­ti:

Git rebase è simile sotto vari aspetti a git merge. Entrambi i comandi integrano le modifiche di un branch in un altro. Git merge non modifica i branch esistenti. Il vantaggio consiste nel fatto che l’intera cro­no­lo­gia resta invariata. In questo modo, tuttavia, si vengono a creare numerosi commit merge non necessari. Git rebase è una soluzione lineare che, grazie al suo approccio in­te­rat­ti­vo, offre numerose pos­si­bi­li­tà di adat­ta­men­to, ma è con­si­de­ra­ta un’opzione per svi­lup­pa­to­ri e svi­lup­pa­tri­ci esperti.

Git rebase offre un grande vantaggio e un po­ten­zia­le svan­tag­gio. L’aspetto positivo di questo comando è che aiuta a mantenere la cro­no­lo­gia del vostro progetto pulita e chiara. Infatti, con git rebase questa risulta strut­tu­ra­ta in modo lineare, senza alcuna bi­for­ca­zio­ne nel progetto. In questo modo la na­vi­ga­zio­ne viene sem­pli­fi­ca­ta e il progetto si mantiene snello. Tuttavia, questa riduzione ha anche lo svan­tag­gio di non poter risalire alla “reale” cro­no­lo­gia del progetto. Alcuni commit possono andare persi, il che, spe­cial­men­te quando si lavora in un team di grandi di­men­sio­ni, può essere causa di conflitti quando si esegue un merge. Git rebase è pertanto un comando efficace e utile che però deve essere usato con cautela.

Questo significa so­prat­tut­to che git rebase non deve essere usato su branch pubblici. Ciò, infatti, cau­se­reb­be l’unione del branch prin­ci­pa­le al vostro branch locale, mentre i membri del team con­ti­nue­reb­be­ro a lavorare su una versione com­ple­ta­men­te diversa. In questo modo sarebbe quindi difficile o ad­di­rit­tu­ra im­pos­si­bi­le unire nuo­va­men­te e sin­cro­niz­za­re tutte le singole sezioni.