Git cherry pick vs rebase: che cosa cambia da usare un metodo all’altro? È quello che scoprirai arrivando fino in fondo a questo articolo!
All’interno di git ci sono non pochi strumenti che permettono di alterare la storia del nostro repository.
Devi sapere che ci sono due strade in particolare: una è il cherry-pick, l’altra è il rebase.
È giusto chiedersi però: che differenze ci sono fra i due metodi? Quando è più giusto usare uno o usare l’altro?
Ciao mi chiamo Lorenzo Neri e sono un informatico: realizzo contenuti per aiutare le persone a padroneggiare l’arte del nuovo millennio, ovvero l’informatica!
Devi sapere che questo articolo, così come tanti altri che trovi sul blog, derivano dalla mia esperienza lavorativa e da ore e ore di bestemmie: per me è solo un piacere sapere che ti possano essere di aiuto.
E quale modo migliore di farmelo sapere, se non iscrivendoti alla mia newsletter per rimanere sempre aggiornato sui miei articoli?
Ora che ti sei registrato alla mia newsletter 😛 dicevamo? Ah certo!
Cherry pick vs rebase: dove sta l’inghippo?
In realtà l’inghippo non sta da nessuna parte.
Così come per tutti gli articoli che ho scritto in merito a GIT che trovi a distanza di un click qui cerco di spiegare le cose nel modo più chiaro possibile: nessun inghippo, giurin giurello!
Seguendo ciò che sono le linee guida di git la differenza fra le due alternative messe a disposizione è abbastanza sottile.
Tramite rebase quello che facciamo è sostanzialmente prendere tutti i cambiamenti che sono stati committati su un branch e trasferirli tutti tutti tutti su un altro branch.
Invece tramite cherry pick possiamo essere un po’ choosy e prendere solo alcuni dei cambiamenti in questione, tradotto solo alcuni commit et voilà! Li applichiamo su un altro branch.
Tutto molto bello ma…
Le cose non stanno del tutto così, vero Lorenzo?
Esatto, mi hai beccato.
Parliamo del comando rebase.
Il comando rebase come dicevamo prima, si occupa di prendere tutta quella serie di modifiche eseguite nel tuo repository al punto X di un determinato branch. Una volta prese tutte queste modifiche, vengono applicate ad un altro branch la cui storia sia qualche punto avanti rispetto ad X e quindi si troverà a un punto storico Y tale che X > Y in termini di età.
A questo punto parliamo di cherry pick.
Con lui non siamo obbligati a creare una storia più recente con un altro branch.
Il comando in sé, ci permette senza alcun dubbio di prendere certi commit, scelti secondo le nostre esigenze, ma non solo.
Possiamo scegliere l’ordine con cui prenderli.
Per intenderci, se nel repository abbiamo i commit A B C D in questo ordine cronologico, noi possiamo prenderli per esempio in questo ordine: D A C B.
Non solo: possiamo applicarli a QUALUNQUE punto della storia del branch in cui è nostra intenzione applicarli.
Di conseguenza, se con il rebase siamo obbligati a prendere tutto quanto e a rispettare una storia data dai due branch in questione beh…
Queste due clausole vengono meno con il cherry pick, ecco quindi spiegata la differenza fra i due metodi.
