Corso
Git è un diffuso sistema di controllo di versione (VCS) usato nello sviluppo software per tracciare le modifiche ai file nel tempo. Facilita la collaborazione permettendo agli sviluppatori di lavorare in parallelo senza sovrascrivere i contributi altrui. Poiché tutti mantengono copie locali complete della cronologia del progetto, ognuno può lavorare offline in autonomia e unire in sicurezza le proprie modifiche quando è pronto.
Un repository remoto, o remote, è una versione del tuo progetto Git ospitata nel cloud tramite un servizio online come GitHub o BitBucket.
In questo articolo esploreremo i remote di Git più nel dettaglio. Se stai iniziando ora con Git, dai un'occhiata al nostro tutorial su Git per principianti.
Che cos'è un Git Remote?
Un remote Git fornisce una posizione centralizzata dove un repository può essere archiviato, condiviso e accessibile da altri. Gli utenti possono pushare le modifiche locali verso il remote e pullare dal remote gli aggiornamenti dei colleghi. I remote sono utili anche per fare backup del codice e per il deploy in produzione.
Un repository locale vive sul tuo computer, così puoi scrivere codice, creare commit e testare le modifiche in locale. Un repository remoto, ospitato online, serve per condividere il codice, collaborare con altri e fare il backup del tuo lavoro. In questo articolo vedremo come sincronizzare le modifiche tra repo locali e remoti usando i comandi Git.
Workflow Git
Un tipico workflow Git inizia "clonando" un repository remoto sulla tua macchina. Dopo il clone, puoi creare un nuovo branch per lavorare su una feature o una fix, effettuare modifiche e fare commit in locale.
Quando il lavoro è pronto, fai "push" del branch verso il remote e apri una pull request per la revisione. Dopo l'approvazione, unisci le modifiche nel branch principale.
Durante tutto il processo, effettui regolarmente il "pull" degli aggiornamenti per mantenere il repository locale allineato con il remote.

Un tipico workflow Git (Immagine dal corso Introduction to Git)
Vediamo questo processo più da vicino.
Clonare un repo
Supponiamo che tu voglia creare una copia di un repository remoto, un'operazione nota come "clonare" il repo. Con una copia locale, puoi modificare il codice e testare nuove funzionalità.
Per usare Git, assicurati che sia installato, poi apri un terminale e usa questo comando: git clone <URL>.
Per esempio, per clonare un progetto chiamato "project" da una pagina GitHub con username "datacamp", usa
git clone https://github.com/datacamp/project.git
Remote predefinito: 'origin'
Quando cloni un repository, Git crea un remote predefinito chiamato origin. Questa etichetta origin funge da alias per l'URL del repository da cui hai clonato.
Nei workflow Git tipici, quando esegui comandi come git push o git pull, Git presume che tu ti riferisca a origin a meno che tu non specifichi un altro remote. Questo semplifica la sincronizzazione delle modifiche tra la tua copia locale e il repository condiviso. Vedremo push e pull più avanti in questo articolo.
Gestire i Git Remote
Operazioni comuni di gestione dei remote includono la visualizzazione dei remote esistenti con git remote e l'aggiunta di un nuovo remote con git remote add.
Visualizzare i remote esistenti
Per vedere i remote esistenti, usa il comando git remote.
git remote
>> origin
Nel nostro esempio, è elencato l'alias del remote origin, ma non viene mostrato l'URL. Se vuoi vedere l'URL associato a ciascun remote, usa il flag -v.
git remote -v
>> origin https://github.com/datacamp/project.git (fetch)
>> origin https://github.com/datacamp/project.git (push)
Aggiungere un nuovo remote
Potresti voler collegare il tuo repository locale a un altro remote. Ad esempio, se hai fatto il fork di un progetto, potresti voler tenere traccia delle modifiche nel repository originale oltre a quelle del remote main. Oppure potresti voler pushare il codice su più piattaforme, come GitHub e GitLab.
Per aggiungere un nuovo remote, usa il comando git remote add <name> <URL>. Aggiungiamo, ad esempio, un remote chiamato new_remote.
git remote add new_remote https://github.com/datacamp/project
Dare un nome al remote è utile per non dover digitare l'URL ogni volta che esegui un merge.
Rinominare e rimuovere remote
Rinominare un remote è semplice. Usa il comando git remote rename <old-name> <new-name>. Ad esempio,
git remote rename new_remote original_remote
Per verificare che il remote sia stato rinominato, elenca i remote con git remote.
Per rimuovere un remote, usa git remote remove <name>. Nel nostro esempio:
git remote remove new_remote
Ora elenca i remote per verificare.
git remote
>> origin
Vediamo che l'unico remote è origin.
Lavorare con i branch remoti
Un branch in Git è un percorso indipendente da main che ti permette di lavorare su cambiamenti separatamente dalla versione principale del progetto. Quando il lavoro è completo e revisionato, puoi unire il branch nel progetto principale.
Elencare i branch remoti
Per elencare i branch remoti, usiamo il comando git branch -r.
git branch -r
>> origin/HEAD -> origin/main
>> origin/main
Interpretiamo l'output. La riga origin/main indica che esiste un branch remoto chiamato main sul remote origin. La riga origin/HEAD -> origin/main mostra che il branch predefinito sul remote è origin/main. Quindi, questo output ti dice che main è il branch predefinito sul remote origin ed è attualmente l'unico branch remoto elencato.
Tracciare un branch remoto
Spesso vorrai collegare un branch locale a un branch remoto per mantenere il codice sincronizzato. Quando un branch locale traccia un branch remoto, puoi pullare e pushare modifiche senza dover specificare ogni volta nomi di remote e branch.
Git tiene anche traccia di quanti commit il tuo branch locale è avanti o indietro rispetto al remoto, facilitando la gestione delle modifiche.
Il comando git checkout --track origin/<branch-name> crea un nuovo branch locale che traccia il branch remoto specificato. Imposta un branch locale con lo stesso nome di <branch-name> e lo collega alla versione remota. In questo modo, i futuri comandi git pull e git push interagiranno automaticamente con il branch remoto corretto. Puoi saperne di più su Git Push e Pull nel nostro tutorial.
Fetch e pull dai remote
Per mantenere il tuo branch locale sincronizzato con le modifiche degli altri sviluppatori, devi importare contenuti nel branch locale. "Pullare" significa scaricare le modifiche più recenti dal branch corrispondente sul remote e fonderle nel tuo branch locale. Questo assicura che tu stia lavorando con il codice più aggiornato.
Supponiamo di voler fetchare tutti i branch dal remote chiamato origin. Si fa con il comando git fetch origin. Se vuoi fetchare solo un branch specifico, come main, specificalo: git fetch origin main.
Dopo il fetch, devi ancora sincronizzare il contenuto unendo le modifiche scaricate al tuo branch locale corrente. Per farlo, esegui git merge origin/<branch-name>, sostituendo <branch-name> con il nome del branch che hai fetchato. Per esempio, per unire le modifiche dal branch remoto main useresti git merge origin/main.
Poiché è comune fetchare e fare merge in sequenza, Git fornisce un singolo comando che fa entrambe le cose: git pull. Ad esempio, per fetchare e unire le modifiche dal branch main sul remote chiamato origin, puoi usare git pull origin main.
Quando conviene usare fetch e merge e quando invece pull? Il processo in due passaggi con fetch e merge ti dà più controllo sull'aggiornamento. Il fetch ti consente di vedere cosa è cambiato sul remote prima di fondere le modifiche nel tuo branch locale. È utile se vuoi rivedere gli update, confrontare le differenze o gestire con attenzione potenziali conflitti.
Usa pull quando sei sicuro che le modifiche sul remote siano sicure da unire subito e vuoi aggiornare rapidamente il branch. È comodo e combina entrambi i passaggi, ma offre meno visibilità prima che il merge avvenga.
Fare push su un repository remoto
Fare "push" dei contenuti da un branch locale a un remote significa inviare le tue modifiche locali al branch corrispondente sul repository remoto. Questo aggiorna il remote con il tuo ultimo lavoro così che altri possano vederlo, farne il pull o costruirci sopra. Il push condivide i tuoi contributi e aiuta a mantenere il repository remoto aggiornato per chi lavora al progetto.
Caricare le modifiche locali sul remote è un processo in tre passaggi.
1. Usa git add per mettere in stage i file che vuoi includere. Per aggiungere tutte le modifiche, usa
git add
Per aggiungere un file specifico, indica il nome del file.
git add <filename>
2. Fai il commit delle tue modifiche. Includi un messaggio che descriva cosa hai fatto.
git commit -m “Your commit message here”
3. Fai push verso il remote.
git push origin branch-name
Esempi pratici
Vediamo alcuni esempi pratici: clonare un repo e collaborare con più remote.
Clonare un repository
Ecco una guida passo passo per clonare un repo.
- Ottieni l'URL del repository. Copia l'URL del repository che vuoi clonare. Questo URL è disponibile dal tuo provider cloud, come GitHub o BitBucket.
- Scegli una directory. Vai nella cartella del tuo computer dove vuoi copiare il repo.
- Clona il repository. Esegui il comando
git clone <URL>. Per esempio, eseguigit clone https://github.com/datacamp/project.Questo crea una nuova cartella chiamata project con i contenuti del repo al suo interno. - Elenca i remote configurati. Dopo il clone, controlla i remote con il comando
git remote.Nel nostro esempio vedraiorigin, che è il nome predefinito che Git assegna al remote da cui hai clonato e al suo URL.
Collaborare con più remote
Quando contribuisci a un progetto open source o collabori tramite una copia personale (fork), è comune lavorare con due remote: origin, che è il tuo fork del repo, e upstream, che è il repo da cui hai fatto il fork. In genere hai accesso in scrittura a origin ma non a upstream.
Ci sono alcune buone pratiche da tenere a mente per gestire più remote.
- Aggiungi il remote
upstream. Dopo aver clonato il tuo fork, tieni traccia del repo originale come upstream:git remote add upstream <URL>. - Tieni aggiornato il tuo fork. Fetch regolarmente le modifiche dal repo upstream usando il comando git fetch upstream. Poi fai merge o rebase di quelle modifiche nel tuo branch locale.
- Evita di pushare sul repo
upstream. Di solito non hai (e non ti serve) accesso in push al repo upstream. Tutte le tue modifiche dovrebbero essere pushate suorigine le pull request aperte da lì. - Usa nomi di branch descrittivi. Mantieni i tuoi branch locali organizzati. È una buona idea nominarli in base alla feature o all'issue su cui stai lavorando.
- Controlla i tuoi remote. Usa
git remote -vper rivedere la configurazione dei remote e verificare che gli URL diorigineupstreamsiano corretti. - Allineati prima di iniziare a lavorare. Prima di iniziare nuovo lavoro, fai sempre il pull delle ultime modifiche da upstream nel tuo branch principale per restare aggiornato ed evitare conflitti successivi.
Best practice e consigli sui Git Remote
Ecco alcune best practice da seguire quando usi i remote di Git:
Mantenere i remote aggiornati
Effettuare regolarmente fetch aiuta a mantenere la tua copia locale del repository aggiornata rispetto alla versione remota. Eseguendo git fetch scarichi le nuove modifiche dal remote senza influenzare il tuo branch corrente.
Questo ti tiene al corrente di ciò che i colleghi hanno pushato, ti permette di confrontare le modifiche e ti aiuta a prepararti per eventuali update o merge necessari. Un fetch costante riduce la probabilità di conflitti e mantiene fluido il flusso di collaborazione.
Col tempo, quando i branch vengono eliminati dal repository remoto, la tua configurazione Git locale può continuare a mostrare quei vecchi branch come branch di tracciamento remoto. Questi sono detti branch di tracciamento remoti "obsoleti".
Per pulire i tuoi branch, esegui git remote prune origin per rimuovere i branch di tracciamento remoto che non esistono più sul remote origin.
Farlo regolarmente aiuta a mantenere il tuo repository locale ordinato, facilita la ricerca dei branch rilevanti e assicura di non fare riferimento a lavori superati.
Gestire i conflitti con i remote
I conflitti remoti possono essere difficili da risolvere. La soluzione migliore è prevenirli assicurandosi che più persone non lavorino sulle stesse parti di codice contemporaneamente. Tuttavia, non è sempre possibile.
Nonostante le buone intenzioni, i conflitti possono capitare. Quando succede, segui questo piano per gestirli in modo efficace.
- Usa
git statusper vedere quali conflitti richiedono la tua attenzione. - Apri i file in conflitto e modificali per risolvere le differenze.
- Usa uno strumento di merge. Strumenti come VS Code o
git mergetoolmostrano confronti affiancati e ti permettono di scegliere quale versione del codice mantenere. - Comunica con il team. Se il conflitto non è chiaro, confrontati con i colleghi prima di risolvere il problema. Assicurati di capire quali righe tenere e quali rimuovere.
- Testa il tuo codice dopo aver risolto il conflitto per assicurarti che nulla sia rotto e che tutto funzioni come previsto.
- Fai il commit delle modifiche. Dopo aver risolto tutti i conflitti, metti in stage i file e crea un commit per completare il merge.
Rebase
Usare git pull --rebase può ridurre la probabilità di conflitti di merge complessi applicando le tue modifiche sopra gli ultimi commit remoti.
Quando usi git pull --rebase, Git prima fa fetch delle modifiche più recenti dal remote, poi applica i tuoi commit locali sopra, come se il tuo lavoro fosse avvenuto dopo.
Questo approccio aiuta a creare una cronologia dei commit più pulita e lineare e può ridurre le possibilità di conflitti di merge disordinati.
Invece di creare un commit di merge che combina le storie, il rebase fa sembrare che le tue modifiche siano state fatte dopo gli aggiornamenti remoti. Puoi saperne di più nel nostro tutorial su Git Rebase.
Conclusione
I remote di Git sono fondamentali per lo sviluppo collaborativo, collegando i repository locali a codebase condivise. In questa guida abbiamo coperto le operazioni essenziali sui remote, tra cui configurazione, sincronizzazione tramite i comandi fetch, pull e push, e gestione di più connessioni remote.
Padroneggiare i concetti trattati può aiutarti a collaborare in modo più efficiente, mantenere una cronologia del progetto chiara e contribuire al lavoro del tuo team di sviluppo.
Per ulteriori informazioni sui branch remoti di git, consulta le risorse di DataCamp.
- Git Checkout Remote Branch: guida passo passo
- Tutorial su Git Push e Pull
- Git Pull Force: come sovrascrivere un branch locale con il remoto
- Corso Introduction to Git
- Corso Intermediate Git
- Corso Advanced Git
- Introduzione ai concetti di GitHub
- GitHub e Git: tutorial per principianti
- Come imparare Git nel 2025: guida completa per principianti
- Git Cheat Sheet
Git Remotes FAQ
Che cos'è un Git remote?
Un Git remote è un collegamento a un repository ospitato su un server, spesso su piattaforme come GitHub, GitLab o Bitbucket.
Come si chiama il remote quando cloni un repository?
Per impostazione predefinita, il remote è aliasato come origin.
Come faccio a vedere quali remote sono configurati?
Il comando git remote -v mostra i nomi e gli URL di tutti i remote collegati al tuo progetto.
Come aggiungo un nuovo remote?
Usa il comando git remote add <name> <url>. Per esempio,
git remote add upstream https://github.com/user/project.git
Cosa succede se faccio push al remote sbagliato?
Manderai le tue modifiche al repository sbagliato. È una buona idea ricontrollare i nomi dei remote usando git remote -v.

