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:
- Eseguire un fetch per recuperare i commit remoti:
git fetch origin - 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. - Eseguire nuovamente il push:
git push origin main
Solo dopo questa integrazione sarà possibile completare la pubblicazione delle modifiche.
Scenari avanzati
- Push di tutti i branch locali:
git push --all origin - Pubblicazione dei tag (per versionamento o release):
git push origin --tags - 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
![]() |
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
![]() |
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 |
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.