Git: Gestione dei repository remoti

Per collaborare efficacemente in un progetto Git, è fondamentale comprendere come gestire i repository remoti. I repository remoti sono versioni dei progetti ospitati su un server (Internet, rete locale o persino la stessa macchina, purché in un percorso distinto).

La gestione dei remoti comprende operazioni quali:

• Aggiungere o rimuovere repository remoti.
• Consultare la loro configurazione.
• Sincronizzare i dati tramite fetch, pull e push.
• Ispezionare e mantenere aggiornate le referenze remote.

Visualizzare i repository remoti 

Per verificare quali repository remoti sono attualmente associati a un progetto Git, è possibile utilizzare il comando:

git remote

Tale comando restituisce l’elenco degli alias (shortname) configurati per i repository remoti. Qualora il repository sia stato clonato da un server remoto, sarà presente almeno l’alias origin, che costituisce la denominazione predefinita attribuita da Git al repository di origine del clone.

FIG 1 - Git remote

Per ottenere, oltre ai nomi, anche gli indirizzi URL associati ai repository remoti (distinti per operazioni di fetch e push), è possibile utilizzare l’opzione -v:

git remote -v

FIG 2 - git remote -v

Un progetto con più collaboratori può avere vari remoti, ciascuno con il proprio URL e protocollo di accesso (HTTPS, SSH, Git).

Aggiungere un nuovo repository remoto

Per aggiungere un nuovo repository remoto e assegnargli un shortname (alias):

git remote add <shortname> <url>

Esempio:

git remote add pd24 https://github.com/Pedestrian24/Hello.git

Da questo momento, sarà possibile richiamare il repository remoto con pd24 invece di digitare l’intero URL.

FIG 3 - git remote add

Sincronizzazione con Repository Remoti: Fetch e Pull

Nell’ambito della collaborazione su progetti Git, una delle operazioni fondamentali consiste nel mantenere il proprio repository locale aggiornato rispetto al repository remoto. A tal fine, Git mette a disposizione due comandi principali: git fetch e git pull.

1. git fetch: Recupero dei dati senza integrazione automatica

Scarica i nuovi dati dal remoto senza modificarne l’integrazione nel branch attuale. Il comando:

git fetch <remote>

provvede a contattare il repository remoto specificato (ad esempio origin) e a scaricare tutte le nuove informazioni (commit, branch, tag) che non sono ancora presenti localmente.

Dopo l’esecuzione di git fetch, il repository locale contiene riferimenti aggiornati a tutti i branch remoti (ad esempio origin/main, origin/dev, ecc.), senza tuttavia modificare il contenuto della working directory o del branch corrente.

Pertanto:

• I dati vengono aggiornati nella copia locale del database Git.
• Non viene modificato il codice attualmente in lavorazione.
• L’integrazione delle modifiche (mediante merge o rebase) deve essere eseguita manualmente dall’utente.

Esempio pratico:

git fetch origin

Scarica dal server remoto origin tutte le modifiche effettuate da altri collaboratori dall’ultimo fetch, lasciando intatto lo stato della propria area di lavoro.

FIG 4 - git fetch origin

2. git pull: Recupero e fusione automatica

Il comando:

git pull <remote> <branch>

rappresenta una scorciatoia che combina due operazioni:

• git fetch
  recupera i dati aggiornati dal repository remoto.
• git merge (o git rebase se configurato)
  integra automaticamente i dati recuperati nel branch locale attualmente attivo.

In caso di repository clonato con il comando git clone, Git configura automaticamente il branch locale predefinito (main o master, a seconda della nomenclatura del server) per tracciare il branch remoto corrispondente (origin/main o origin/master).

Pertanto, il semplice comando:

git pull

provvede a scaricare e integrare nel branch locale eventuali modifiche presenti sul server remoto di origine.

FIG 5 - git pull

A partire da Git 2.27, se la variabile di configurazione pull.rebase non è impostata, l’esecuzione di git pull genera un avviso, invitando l’utente a scegliere un comportamento predefinito

Configurazioni consigliate:

• Comportamento standard (merge)
  git config --global pull.rebase "false"   
  In questo caso, git pull tenta un fast-forward quando possibile, altrimenti effettua un merge commit.
• Comportamento alternativo (rebase)
  git config --global pull.rebase "true"   
  In questo scenario, le modifiche locali vengono riallineate sopra la cronologia del branch remoto, mantenendo una storia più lineare e priva di commit di merge superflui.

Pubblicazione delle Modifiche su Repository Remoti (Push)

Una volta raggiunto uno stato stabile del proprio progetto locale, è necessario condividere le modifiche con gli altri collaboratori pubblicandole su un repository remoto.

Questa operazione viene eseguita tramite il comando:

git push <remote> <branch>

Concetto di Push

Il comando git push invia i commit presenti nel branch locale specificato verso il corrispondente branch remoto.

Ad esempio, per pubblicare il contenuto del branch main(o master, a seconda della nomenclatura utilizzata) sul repository remoto di default origin, è sufficiente eseguire:

git push origin main

In questo modo, lo stato corrente del branch locale master viene replicato nel corrispondente branch remoto origin/main.

Requisiti e condizioni per il push

L’operazione di push ha successo solo se:

• L’utente dispone di permessi di scrittura sul repository remoto.
• La cronologia del branch remoto è compatibile con quella del branch locale.

Nel caso in cui un altro collaboratore abbia già eseguito un push al branch remoto dopo il vostro ultimo aggiornamento locale, Git rifiuterà l’operazione per evitare la perdita o la sovrascrittura dei commit altrui.

Sincronizzazione prima del push

Quando il push viene rifiutato a causa di divergenze, è necessario:

1. Eseguire un fetch per recuperare i commit remoti:
   git fetch origin 
2. Integrare tali modifiche nel branch locale, utilizzando:
   git merge origin/main
   fusione classica, mantiene entrambe le linee di sviluppo.
   git rebase origin/main
   riallineamento lineare, utile per cronologie pulite.
   
3. Eseguire nuovamente il push:
   git push origin main

Solo dopo questa integrazione sarà possibile completare la pubblicazione delle modifiche.

Scenari avanzati

1. Push di tutti i branch locali:
   git push --all origin
   
2. Pubblicazione dei tag (per versionamento o release):
   git push origin --tags
   
3. Forzare il push (operazione rischiosa): 
   git push --force origin master
   Questo comando sovrascrive la cronologia remota con quella locale, potenzialmente cancellando il lavoro di altri. Deve essere utilizzato solo in scenari controllati (es. riscrittura della cronologia prima della pubblicazione ufficiale).

FIG 6 - git push origin main

Ispezione di un Repository Remoto (show)

Per gestire in maniera efficace le interazioni con repository remoti, Git mette a disposizione il comando:

git remote show <nome-remoto>

Questo strumento consente di ottenere una panoramica dettagliata sulle configurazioni associate a un determinato remote, come ad esempio l’URL di fetch e push, i branch tracciati e le impostazioni di sincronizzazione.

Utilizzo di base

Ad esempio, per ispezionare il remote predefinito origin:

git remote show origin

FIG 7 - git remote show origin

L’output restituisce informazioni essenziali, tra cui:

• Fetch/Push URL. Gli indirizzi utilizzati per scaricare (fetch) o pubblicare (push) dati.
• HEAD branch. Il branch predefinito del remote (spesso master o main).
• Remote branches. I branch remoti tracciati dal repository locale.
• Branch locali configurati per pull/push. Le associazioni automatiche di sincronizzazione.

Output avanzato in scenari complessi

In progetti di grandi dimensioni o con più branch remoti, l’output può essere molto più articolato.

FIG 8 - git remote show origin

In questo caso, emergono ulteriori informazioni:

• Branch nuovi (new)
  individuati sul server, ma non ancora scaricati localmente. Verranno sincronizzati al prossimo fetch.
• Branch obsoleti (stale)
  presenti localmente ma rimossi dal server. Git suggerisce di eliminarli con:
  git remote prune origin
• Associazioni multiple
  un branch locale può essere configurato per sincronizzarsi automaticamente con un branch remoto specifico.

Casi d’uso pratici

• Verifica rapida della configurazione remota prima di eseguire git pull o git push.
• Identificazione di branch obsoleti per mantenere un repository locale pulito.
• Controllo dei permessi e degli URL (utile quando si lavora con remoti accessibili sia via HTTPS che SSH).
• Diagnosi di problemi di sincronizzazione, ad esempio quando un branch non è correttamente tracciato.

Rinomina ed Eliminazione dei Repository Remoti (rename, remove)

La gestione dei repository remoti in Git non si limita alla loro configurazione iniziale: in determinati scenari può essere necessario rinominare un remote per una migliore leggibilità, oppure rimuoverlo se non più utilizzato. Git mette a disposizione comandi specifici per entrambe le operazioni.

1. Rinomina di un Remote

Per modificare il nome abbreviato (shortname) di un remote si utilizza:

git remote rename <vecchio-nome> <nuovo-nome>

Esempio

Se si desidera rinominare un remote chiamato pd24 in pippo:

git remote rename pd24 pippo
git remote

FIG 9 - git remote rename

L’operazione non si limita a rinominare il remote, ma aggiorna automaticamente anche tutti i riferimenti ai branch di tracking.

Ad esempio:

• Prima: pd24/main
• Dopo: pippo/main

Questo garantisce coerenza e riduce il rischio di errori manuali.

2. Rimozione di un Remote

Se un remote non è più necessario (ad esempio perché il server è stato spostato, un mirror è stato dismesso o un collaboratore non contribuisce più), è possibile eliminarlo con:

git remote remove <nome>

oppure, in alternativa:

git remote rm <nome>

Esempio

Per rimuovere il remote pippo:

git remote remove pippo
git remote

FIG 10 - git remote remove

Dopo l’eliminazione:

• Tutti i remote-tracking branch associati a quel remote vengono rimossi.
• Le configurazioni locali legate al remote (ad esempio impostazioni di fetch e push) vengono eliminate.

Tabella di Sintesi: Principali Operazioni sui Repository Remoti

Comando	Descrizione	Esempio
git remote -v	Elenca i remoti configurati con i rispettivi URL	git remote -v
git remote add <nome> <url>	Aggiunge un nuovo remoto	git remote add pd24  https://github.com/Pedestrian24/Hello.git
git fetch <remote>	Scarica i dati dal remoto senza integrarli	git fetch origin
git pull	Scarica e integra i dati dal remoto	git pull origin master
git push <remote> <branch>	Invia i commit locali al remoto	git push origin main
git remote show <remote>	Mostra dettagli di configurazione di un remoto	git remote show origin
git remote rename <old> <new>	Rinomina un remoto	git remote rename pd24 pippo
git remote remove <nome>	Rimuove un remoto e le relative configurazioni	git remote remove pippo

Best Practice

• Usare nomi coerenti: origin per il repository principale, upstream per il fork originale.
• Controllare sempre con git fetch prima di un git pull: riduce i conflitti e rende più prevedibile il flusso.
• Evitare git push --force salvo nei branch personali: può riscrivere la cronologia e creare problemi ai collaboratori.
• Pulire i branch remoti obsoleti con:
  git remote prune origin
• Preferire SSH a HTTPS per ambienti professionali: maggiore sicurezza e praticità nell’autenticazione.