Git Pull Force: come sovrascrivere un branch locale con il remoto

Quando considerare la sovrascrittura delle modifiche locali

In generale, sovrascrivere le modifiche locali in questo modo va contro l’uso previsto di Git. Quasi per ogni situazione esiste un workflow Git appropriato per risolverla. Tuttavia, spesso questi richiedono una comprensione più profonda di Git e più tempo per essere eseguiti. Anche se non è una best practice, sovrascrivere le modifiche locali a volte può essere il modo più rapido per portare a termine il lavoro.

A me di solito capita quando lavoro su una funzionalità che non conosco bene. Inizio creando un branch e facendo alcuni commit. Quando mi blocco, chiedo aiuto a un collega. Lui riparte da un commit precedente, prima dell’errore, risolve il problema e fa push delle sue modifiche. A quel punto devo sostituire la mia versione locale con quella remota aggiornata, scartando le modifiche locali, così posso continuare a lavorare sulla funzionalità.

Un altro esempio è quando c’è un conflitto e ritengo più difficile o dispendioso in termini di tempo risolverlo piuttosto che reimplementare le nostre modifiche sull’ultima versione del codice.

Qualunque sia il motivo, assicurati sempre che quelle modifiche non siano davvero necessarie e possano essere eliminate in sicurezza, oppure esegui un backup del branch per evitare di perdere lavoro importante.

Come sovrascrivere correttamente le modifiche locali

Il primo passo è recuperare (scaricare) i contenuti più recenti dal repository remoto sulla nostra macchina locale. Questo si fa usando il comando fetch di git:

git fetch

Per impostazione predefinita, questo recupererà i contenuti del branch corrente, che di solito è ciò che ci serve. Possiamo, in alternativa, specificare il branch che vogliamo scaricare (sostituendo di seguito <branch_name> con il nome del branch che vogliamo fetchare):

git fetch origin/<branch_name>

In alternativa, possiamo usare l’opzione --all per scaricare tutto:

git fetch –all

Il fetch delle modifiche dal repository remoto non influirà sui file nella directory del branch di lavoro corrente. Il comando fetch scarica le modifiche dal repository remoto ma non le unisce. Il repository locale mantiene una vista sia dei file locali sia di quelli remoti, e il fetch aggiorna la vista dei file remoti.

Dopo aver scaricato le modifiche dal repository remoto, possiamo usare il comando reset di git per riportare il branch di lavoro corrente a uno stato specifico:

git reset --hard origin/<branch_name>

L’opzione --hard è necessaria per assicurare che le modifiche locali vengano sovrascritte da quelle remote. Nel comando sopra, abbiamo scelto di sostituire il branch di lavoro corrente con origin/<banch_name>, che corrisponde alla versione remota di quel branch appena fetchata.

Il comando git reset eliminerà le modifiche locali, anche se già committate. Si consiglia quindi di creare un backup locale del branch corrente prima di eseguire quel comando. Questo si può fare con:

git branch <name_of_the_backup_branck>

Sostituendo <name_of_the_backup_branch> con il nome che vuoi dare al branch di backup.

Mettendo tutto insieme, possiamo sovrascrivere tutte le modifiche locali di un dato branch con l’ultima versione remota facendo così:

git fetch
git branch <name_of_the_backup_branch>
git reset --hard origin/<branch_name>

Se vuoi approfondire il lavoro con i branch in Git, dai un’occhiata al tutorial su come clonare un branch specifico.

Pulizia completa eliminando i file non tracciati

Git non toccherà i file non tracciati (file che non sono mai stati aggiunti con git add). Se vogliamo eliminare anche questi file, possiamo usare:

git clean -fdx

Questo è un comando pericoloso che viene usato per rimuovere i file non tracciati dalla working directory. È fondamentale usarlo con cautela perché elimina definitivamente questi file, rendendo impossibile recuperarli tramite Git. Ecco una panoramica delle opzioni del comando:

• -f: forza l’esecuzione dell’operazione di clean. Senza questo flag, come misura di sicurezza per prevenire perdite accidentali di dati, Git rifiuterà di eliminare i file non tracciati dalla working directory.
• -d: indica a git clean di rimuovere non solo i file non tracciati ma anche le directory non tracciate. Per impostazione predefinita, git clean prende di mira solo i file non tracciati e ignora le directory.
• -x: per impostazione predefinita, git clean rispetta le regole di .gitignore e non rimuove file o directory che corrispondono a tali pattern. Includere -x ignora questo comportamento, istruendo Git a rimuovere anche file/directory ignorati da .gitignore o da altre regole di ignore. Ne risulta una pulizia molto accurata, che rimuove tutti i file non tracciati nel repository, inclusi output di build, file di log e altri artefatti generati che di solito sono ignorati.

Capire Git Pull

Il modo abituale per aggiornare il repository locale con le modifiche remote è usare il comando git pull. Tuttavia, questo comando non può essere usato per sovrascrivere le modifiche locali perché git pull proverà a unire la nostra versione locale con quella remota.

Dietro le quinte, git pull esegue i seguenti passaggi:

1. Usa git fetch per scaricare la versione più recente del repository remoto.
2. Usa git merge per unire i branch locale e remoto.

A causa del passaggio di merge, git pull non è un comando adatto quando vogliamo ignorare e scartare le modifiche locali.

E il git pull --force?

Consultando la documentazione del comando git pull vediamo che offre un’opzione --force. È un equivoco comune pensare che questa opzione forzi l’esecuzione di git pull cancellando le modifiche locali con quelle remote.

Quando forniamo l’opzione --force a git pull, questa viene passata a git fetch. Quindi git pull --force esegue i seguenti passaggi:

1. git fetch --force
2. git merge

Abbiamo visto che fetch serve ad aggiornare la vista locale del repository remoto. Se l’unica differenza tra il tuo repository locale e quello remoto sono alcuni commit mancanti (il branch locale è indietro rispetto alla versione remota), allora git fetch aggiornerà semplicemente la vista locale aggiungendo quei nuovi commit alla cronologia.

Tuttavia, potrebbe essere che qualcuno abbia riscritto la cronologia dei commit del branch remoto rendendola incompatibile con la vista locale. In questo caso, fetch non funzionerà.

Possiamo aggirare il problema usando l’opzione --force, che forza Git a ignorare la cronologia locale e a sovrascriverla con quella remota. 

Vediamo quindi che l’opzione --force serve a forzare la sovrascrittura della cronologia dei commit e non ha nulla a che vedere con l’ignorare le modifiche locali nella directory del branch di lavoro.

Integrare le modifiche locali

Sovrascrivere le modifiche locali con quelle remote non è una pratica comune in Git, ma può essere utile in alcuni casi in cui non vogliamo gestire i conflitti o non ci interessano le modifiche locali.

Merge

Di solito si fa pull delle modifiche e si gestiscono i conflitti. Le persone tendono a temere i conflitti. Alcuni conflitti possono essere impegnativi, ma non è spesso così. Un conflitto si verifica quando:

1. Sia il branch locale che quello remoto hanno modifiche sulla stessa parte di un file.
2. Un file viene eliminato da una parte e modificato dall’altra.

In questi casi, Git non può indovinare quali modifiche vogliamo mantenere, quindi dobbiamo indicarglielo manualmente. Git evidenzierà il conflitto nei file in questo modo:

Per risolvere un conflitto, modifichiamo il file eliminando queste righe tranne quelle che vogliamo mantenere. Dopo aver gestito tutti i conflitti, possiamo fare commit delle modifiche. Per una guida approfondita, consulta questo tutorial su come risolvere i conflitti di merge in Git.

Cherry-pick

Se vogliamo davvero prima allineare la versione locale a quella remota e poi integrare eventualmente le nostre modifiche, possiamo portare i commit dal branch di backup al branch corrente, così:

git cherry-pick <commit_hash>

Qui, <commit_hash> è l’hash del commit che vogliamo integrare. Questo presuppone che, prima di eseguire git reset, abbiamo creato un branch di backup con git branch <name_of_the_backup_branck> e che le modifiche locali siano state committate.

Per trovare il <commit_hash>, possiamo elencare gli hash dei commit nel branch di backup usando il seguente comando:

git log <name_of_the_backup_branck>

Stash

In alternativa, se non vogliamo fare commit delle modifiche o creare un branch di backup, possiamo mettere da parte (stash) le modifiche prima del merge usando:

git stash

Questo comando consente di salvare temporaneamente il lavoro attuale senza committarlo nella cronologia del branch. Lo stash mette da parte le modifiche, permettendoti di avere una working directory pulita.

Dopo il reset, possiamo riportare le modifiche con il seguente comando:

git stash pop

Usando lo stash, l’intero workflow potrebbe essere qualcosa del genere:

git fetch
git stash
git reset --hard origin/<branch_name>
git stash pop

Per saperne di più, consulta questo cheat sheet con stash e altri comandi git.

Conclusione

Pur non essendo una best practice, a volte ci troviamo nella situazione in cui vogliamo semplicemente far coincidere il nostro branch locale con i contenuti del branch remoto, scartando le modifiche locali.

Esiste l’idea errata che ciò si ottenga con git pull --force. Questo è sbagliato perché git pull --force combina git fetch --force e git merge. Pertanto, tenta di unire le modifiche locali con quelle remote, non di sovrascriverle.

Il modo corretto per sovrascrivere le modifiche locali con i contenuti del repository remoto è:

git fetch
git reset --hard origin/<branch_name>

Il comando git reset va usato con cautela perché eliminerà le modifiche locali, anche se sono state committate. Se avevamo commit locali e abbiamo creato un branch di backup, possiamo recuperarli con git cherry-pick. Se non abbiamo fatto commit e vogliamo salvare temporaneamente il lavoro locale, possiamo usare git stash prima del reset e poi git stash pop per riportare le modifiche.