Ultimo concetto base da chiarire è quello del o dei Remote in Git, inteso nell'accezione di repository remoto a cui in qualche modo il mio repository locale è collegato.
Abbiamo visto che possiamo copiare sulla nostra macchina un repository pre-esistente su un server remoto tramite git clone.
Nel momento in cui git clone crea la copia locale, salva anche il riferimento (URL) al repository da cui ha recuperato i dati (commit, branch, …). Tale riferimento prende, appunto, il nome di “remote” oppure “remote repository”. Il nome del remote iniziale di un repository clonato è spesso origin.
La connessione instaurata tra il branch locale e il branch remoto è utile sia per recuperare in seguito dal remote nuovi branch e nuovi commit, sia per inviare i propri branch e i propri commit.
In particolare, in modo concettualmente simile a quello che succede tra working copy e branch da cui è stato estratto il commit, i branch presenti nella propria copia locale possono essere collegati a branch presenti nel branch remote. È, quindi, possibile sapere se la propria working copy e il proprio branch hanno differenze (in più o in meno) rispetto alla controparte remota.
Come vedremo meglio in seguito, quando affronteremo gli sviluppi in collaborazione, è possibile avere più remote a cui il nostro repository locale punta e scegliere da quale remote recuperare dati o a quale remote inviare dati di volta in volta.
Anche in questo caso Git non è prescrittivo sull’uso dei remote, sta ai team scegliere come usare i remote per gestire diverse modalità di collaborazione o di pubblicazione del codice sorgente
