Dopo aver introdotto i comandi git rebase in Git e git merge in Git e dopo aver introdotto possibili strategie di workflow, vediamo più nel dettaglio come e perché scegliere l’uno o l’altro comando in base al progetto, all'esigenza e alla finalità che si vuole raggiungere.
Molto spesso, infatti, l’attività di rebase è etichettata come difficile e pericolosa per chi si avvicina a Git, ma, come abbiamo visto parlando dei vari workflow, è anche importante saper mantenere la history della propria working copy e del branch principale di sviluppo il più possibile pulita, al fine di comprendere poi meglio l’evoluzione del progetto.
La prima cosa importante per poter confrontare merge e rebase è che i due comandi (o approcci) servono a risolvere lo stesso problema: integrare modifiche presenti su un branch all’interno di un altro branch.
Merge vs Rebase
L’opzione merge in Git
Scegliendo l’opzione merge in Git per riportare e modifiche di main su feature, creiamo un merge commit sul branch feature, che “incorpora” le modifiche presenti sul branch principale e lega insieme i due branch.
git merge feature main
Opzione Merge
L’operazione di merge è “non distruttiva”. Modifiche e commit preesistenti al merge non vengono alterati in alcun modo.
D’altro canto, il branch feature conterrà un merge commit “estraneo” per ogni volta che sarà necessario incorporare modifiche dal branch principale. Se il branch feature vive molto a lungo e ci sono modifiche frequenti al branch main, sarà difficile comprendere l’esatta cronologia delle modifiche.
Inoltre, se consideriamo uno sviluppo a “feature branch”, sarà sempre necessario pensare a cosa accadrà quando riporteremo il branch di feature sul ramo principale.
