L’opzione rebase in Git

Scegliendo l’opzione rebase in Git per riportare e modifiche di main su feature, l’intero branch feature viene “spostato”, ricreando i singoli commit che ne facevano parte.

git checkout feature
git rebase main

Opzione Rebase

Il vantaggio dell’opzione rebase in Git è proprio la possibilità di ottenere una history di progetto più chiara. Non esiste più il commit di merge e la storia del progetto risulta più ordinata (dal punto di vista di cosa è entrato a far parte del branch principale).

Ci sono, però, due compromessi da tenere in considerazione:

• con il rebase non è più possibile sapere quando le modifiche del branch principale sono state riportate nel branch feature
• se non si segue la regola d’oro del rebase, bisogna essere pronti a gestire problemi di collaborazione tra web developers

La regola d’oro del rebase in Git

Mai fare rebase su un branch pubblico

Per capire meglio il perché di questa regola d’oro, supponiamo che per incorporare le modifiche presenti nei due branch avessimo optato per fare rebase del branch main sul branch feature. Avremmo ottenuto la seguente situazione:

Opzione Rebase

Il rebase sposta tutti i commit precedentemente in main sulla punta di feature, creando nuovi commit. Ma ciò accade solo sul proprio repository locale. Dal momento che il rebase si traduce in commit nuovi di zecca, Git penserà che la cronologia del proprio ramo main si sia discostata da quello repository remoto e non sarà possibile fare push, se non usando l’opzione –force.

Scegliendo di fare push con force, potremmo effettivamente riallineare il nostro repository locale e quello remoto, ma tutti gli altri collaboratori avranno ancora il branch main originale e non sarà loro possibile aggiornare in modo semplice i propri repository.

Ovviamente, come tutte le regole d’oro, ci sono situazioni in cui è necessario doverla infrangere. Tutto dipende ovviamente dal progetto, dal team e dalla necessità. È possibile, infatti, accordarsi sul riscrivere la history di un feature branch pubblicato sul repository remoto prima di farne il merge il branch principale (per esempio perché il merge presenta dei conflitti e si vuole risolvere tali conflitti cambiando direttamente i commit nel branch che vanno in conflitto) e verificare se la risoluzione, effettivamente, lascia tutto funzionante.

L’importante è sapere cosa si sta facendo e su chi, eventualmente, la cosa ha impatto.