[risolto] Git pull warning: L'esecuzione di un pull senza specificare come riconciliare branch divergenti non è consigliata

A partire da Git versione 2.27 (fornita a corredo di Ubuntu 20.10, Groovy Gorilla), il "solito" comando git pull mostra un avviso: warning: L'esecuzione di un pull senza specificare come riconciliare branch divergenti non è consigliata. L'operazione va comunque a buon fine, ma molti di noi vorranno sicuramente capire il significato di questa novità ed evitare che il messaggio si presenti ogni volta. In questo articolo vedremo dunque sia come fare, in pratica, per evitare la comparsa del warning, sia che cosa significhi

» Leggi anche: Commit! Pull! Push! - Guida rapida a Git per professionisti impegnati

Il messaggio completo è il seguente:

warning: L'esecuzione di un pull senza specificare come riconciliare branch divergenti non è consigliata. È possibile sopprimere questo messaggio eseguendo uno dei seguenti comandi prima di eseguire il prossimo pull:

git config pull.rebase false # merge (strategia predefinita)

git config pull.rebase true # rebase

git config pull.ff only # esegui solo fast forward

Puoi sostituire "git config" con "git config --global" per impostare una preferenza predefinita per tutti i repository. Puoi anche passare gli argomenti --rebase, --no-rebase o --ff-only sulla riga di comando per eseguire l'override del valore predefinito configurato per una singola invocazione.

Se il sistema operativo è in inglese, viene invece mostrato così:

warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull:

git config pull.rebase false # merge (the default strategy)

git config pull.rebase true # rebase

git config pull.ff only # fast-forward only

You can replace "git config" with "git config --global" to set a default preference for all repositories. You can also pass --rebase, --no-rebase, or --ff-only on the command line to override the configured default per invocation.

GIt: come specificare come riconciliare branch divergenti

A chi cerchi una soluzione rapida, eccola servita: basta ri-eseguire il comando aggiungendo un'opzione:

git pull --no-rebase

Il risultato di questo comando è un merge esattamente uguale a quello che avremmo ottenuto eseguendo solo git pull con le versioni precedenti di Git

Per non dover esplicitare ogni volta l'opzione e tornare ad usare il semplice git pull come al solito senza ricevere avvisi, è sufficiente impostare l'opzione come default:

git config --global pull.rebase false

Perché questa novità?

La novità è probabilmente stata introdotta per forzare l'utente a prendere una decisione consapevole circa quello che succede con il comando git pull.

Generalmente, git pull è una semplice scorciatoia per eseguire in sequenza le operazioni fetch e merge (i due comandi mostrati poco fa ripristinano esattamente questo comportamento). Questa è la scelta più sicura

Per la massima pulizia dello storico (history) dei commit, però, molti gruppi di lavoro preferiscono usare git pull --rebase, ovvero una scorciatoia per i comandi fetch e rebase.

Tramite questo warning, la nuova versione di Git ci invita ad impostare esplicitamente la nostra modalità preferita fra le due.

git merge e git rebase: quali differenze?

In definitiva, dunque, qual è la differenza pratica fra git pull --no-rebase (fetch e merge, ovvero la modalità generalmente utilizzata di default senza specificare opzioni) rispetto a git pull --rebase (fetch e rebase)?

L'argomento, parecchio articolato, è magnificamente spiegato qui. In questa sede, mi limito ad aggiungere che, personalmente, preferisco evitare rebase perché è sempre possibile che qualche collega partecipi ai miei feature branch o che io debba contribuire ai loro, situazione in cui l'uso di rebase crea grossi problemi.

Più in generale, credo che il principale vantaggio di rebase rispetto a merge (ovvero mantenere più pulita la history) sia poco interessante se commensurato al maggior rischio di creare problemi, se non altro quando si tratta di piccoli gruppi di lavoro. È però innegabile che, con team molto ampi e decine di contributi integrati sul ramo principale, la bilancia penda in favore di rebase.