Come gestire le repository remote in Git

In questa lezione parleremo di un po’ di comandi, ma che, a mio avviso, dovrebbe essere presi tutti quanti insieme per essere capiti veramente.

Finora abbiamo usato una sola repository, Git però eccelle anche nella gestione di repository multiple.

Queste possono essere memorizzate localmente o accessibili dalla rete.

Quello che abbiamo visto finora si applica anche con le repository multiple, ma ci sono dei comandi in Git specifici per gestire più repository.

Clonare una repo

Già visto nella lezione su git blame, git clone è il comando che ci permette di duplicare (clonare per l’appunto) una repository.

1$ git clone <nome-repo> <nome-clone>

Verrà quindi presa la directory con il nome specificato e ne creerà una nuova con il secondo nome specificato.

Questo comando è eseguibile anche con repository che si trovano, ad esempio, su GitHub.

Per clonare una repository che si trova su github basta fare

1$ git clone <indirizzo-repo> [<nome-directory>]

Il nome directory è opzionale.

Accedendo alla directory creata dal comando git clone possiamo vedere che c’è esattamente quello che avevamo nella directory originale.

Sbirciando la cronologia vedremo un output simile a questo:

1* 59b4f92 2023-07-22 | Aggiunte nuove pagine (HEAD -> main, origin/main, origin/HEAD) [Manuel Ricci]
2* ae9a59c 2023-07-22 | First Commit [Manuel Ricci]

Per quanto tutto sembra uguale, c’è qualcosa che effettivamente non ci torna. Cos’è quell’origin?

L’origine di origin

Eseguendo il comando git remote vedremo che ci viene restituito origin, indichiamo un pochino più a fondo eseguendo il comando:

1$ git remote show origin
2* remote origin
3  Fetch URL: /home/manuel/code/corso-git/rebase
4  Push  URL: /home/manuel/code/corso-git/rebase
5  HEAD branch: main
6  Remote branch:
7    main tracked
8  Local branch configured for 'git pull':
9    main merges with remote main
10  Local ref configured for 'git push':
11    main pushes to main (up to date)

origin è la nostra repository originale. O meglio ancora, si tratta della nostra repository remota.

Solitamente sono in un’altra macchina, possibilmente sul server centralizzato.

Origin è un nome che viene assegnato di default ed è pratica comune usarlo per la repository centralizzata primaria.

Gestire le repository remote

Le repo remote possono essere aggiunte, rinominate, eliminate e, come già visto, consultate. I comandi per poterlo fare sono:

1$ git remote add <nome> <indirizzo-o-percorso>
2$ git remote show <nome>
3$ git remote rename <nome-originale> <nuovo-nome>
4$ git remote remove <nome>

L'impiego del comando penso sia abbastanza chiaro.

Visualizzare le branch remote

Con il comando git branch possiamo visualizzare le branch remote grazie all’uso del flag -a.

1$ git branch -a
2* main
3  remotes/origin/HEAD -> origin/main
4  remotes/origin/main

Per quanto nella nostra cronologia siano presenti tutte le commit, le branch remote non sono trattate come branch locali, se vogliamo una branch presente in repo, dobbiamo crearla per i fatti nostri. Vedremo più avanti come fare.

Sincronizzarsi con la repo remota

Se sulla repository remota dovessero essere fatte delle modifiche, vogliamo far sì che il nostro clone sia aggiornato. Facendo quindi delle modifiche alla nostra repo originale e opportunamente salvate con una commit. Possiamo procedere alla sincronizzazione, la quale può avvenire con l’utilizzo di due comandi.

Git fetch per scaricare le modifiche senza applicarle

git fetch è un comando usato per scaricare contenuto da una repository remota. Rispetto a git pull, git fetch è considerato un comando più sicuro e non distruttivo.

Il motivo sta proprio nel fatto che le modifiche scaricate non vengono immediatamente applicate. L’esito del git fetch è molto simile a quello di aver creato una branch separata e averci fatto delle modifiche. Se dovessi interrogare il nostro log vedremmo qualcosa di simile.

1$ git hist --all
2* 8a3ec40 2023-07-22 | Aggiunti nuovi contatti (origin/main, origin/HEAD) [Manuel Ricci]
3* 59b4f92 2023-07-22 | Aggiunte nuove pagine (HEAD -> main) [Manuel Ricci]
4* ae9a59c 2023-07-22 | First Commit [Manuel Ricci]

Se vi state chiedendo se è il momento di fare un merge, avete ragione.

Unificare ciò che è stato scaricato con git fetch

Per poter unificare ciò che è stato scaricato con git fetch possiamo eseguire un normalissimo merge, facendo attenzione ad usare la nomenclatura corretta.

1$ git merge origin/main

Verrà quindi fatto un fast-forward e l’esito sarà che la nostra repo clonata sarà di nuovo sincronizzata con quella remota. Se invece volessi fare fetch e merge insieme, in un unico comando? Beh quello è git pull

Git pull per scaricare e applicare le modifiche

Ora penso sia più chiara l’affermazione che fetch è più sicuro e meno distruttivo. git pull è la scorciatoia per poter eseguire git fetch e git merge.

1$ git pull

è l’equivalente di

1$ git fetch
2$ git merge origin/main

Aggiungere una tracking branch

In precedenza ho scritto che per quanto nella nostra cronologia siano presenti tutte le commit, le branch remote non sono trattate come branch locali, se vogliamo una branch presente in repo, dobbiamo crearla per i fatti nostri. Se l’esigenza è quella di sincronizzarsi con una branch remota, possiamo creare una tracking branch che in sostanza è una branch locale che tiene sott’occhio quella remota.

Per poterla creare possiamo eseguire il comando:

1$ git branch --track <nome-branch> <nome-branch-remota>

Se daremo un occhio alla cronologia vedremo che adesso anche la branch remota e quella locale sono sincronizzate.

Sincronizzare la repository originale con quella clonata

Se il discorso in termini di sincronizzazione dovesse essere al contrario? Cioè noi facciamo una modifica sulla repo clonata e vogliamo fare in modo che quelle modifiche siano anche nell’originale.

Fatte le modifiche ci basterà eseguire il comando git push

1$ git push origin main

Andando a vedere la repo originale vedremo che la modifica è già disponibile.

Dal nostro computer a Internet

Tutto quello che abbiamo visto è possibile farlo anche con delle repo che non sono sul nostro computer, ma ad esempio hostate su servizi come GitHub, GitLab o Bitbucket.

Conclusioni

Sono stati tanti i comandi, ma come detto all’inizio aveva senso affrontarli tutti insieme invece che frammentati. Nella prossima lezione ci “rilassiamo” con le repository di condivisione (bare) prima delle ultime lezioni super toste su bisect, hook e reflog.