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.
Caricamento...
Diventiamo amici di penna? ✒️
Iscriviti alla newsletter per ricevere una mail ogni paio di settimane con le ultime novità, gli ultimi approfondimenti e gli ultimi corsi gratuiti puubblicati. Ogni tanto potrei scrivere qualcosa di commerciale, ma solo se mi autorizzi, altrimenti non ti disturberò oltre.
Se non ti piace la newsletter ti ricordo la community su Discord, dove puoi chiedere aiuto, fare domande e condividere le tue esperienze (ma soprattutto scambiare due meme con me). Ti aspetto!