Tutorial Git: creare un repository su GitHub o GitLab e clonarlo

Un promemoria utile prima di cominciare, sviluppato nell’introduzione del tutorial: Git gira sulla tua macchina, GitHub e GitLab sono soltanto degli host per repository Git.

Ci sono due modi di arrivare a un progetto tracciato da Git e collegato a GitHub o GitLab, e la scelta dipende solo dall’ordine in cui le cose esistono. O il repository remoto esiste già e tu lo recuperi: è clonare. Oppure hai una cartella sulla tua macchina e la pubblichi: è inizializzare e poi fare push. Questo capitolo tratta entrambi i casi.

Creare il repository remoto

Su GitHub, il pulsante New dalla home, oppure l’indirizzo github.com/new. Su GitLab, New project poi Create blank project.

Al momento della creazione ci sono tre decisioni da prendere.

Il nome. Diventa una parte dell’URL del repository. Preferisci le minuscole e i trattini, senza accenti né spazi.

La visibilità. Pubblico significa leggibile da chiunque, cronologia completa compresa e quindi anche tutto ciò che ci avrai committato per errore. Privato limita l’accesso alle persone che inviti. Nel dubbio, parti da privato: passare da privato a pubblico più tardi è immediato, il contrario non cancella ciò che è già stato copiato.

Il file README. Spunta la casella solo se hai intenzione di clonare il repository. Se hai già una cartella da pubblicare, lascia il repository completamente vuoto, altrimenti dovrai riconciliare due cronologie che non hanno niente in comune.

Scegliere tra indirizzo SSH e indirizzo HTTPS

Una volta creato il repository, la pagina ti propone un URL in due forme. Puntano allo stesso repository e cambiano solo per il metodo di autenticazione.

Fai attenzione alla differenza di forma: l’indirizzo SSH usa i due punti dopo il nome host, non una barra. E soprattutto il dominio cambia a seconda del servizio. Dare un URL github.com per un progetto ospitato su GitLab è un classico errore di copia-incolla.

Se hai messo una chiave SSH nel capitolo precedente, prendi l’indirizzo SSH: non ti verrà più chiesto niente. L’indirizzo HTTPS impone di fornire un token di accesso personale, che il gestore di credenziali può memorizzare.

Primo caso: il repository esiste, tu lo cloni

È la situazione di chi entra in un progetto, o di chi ha creato il repository con un README.

git clone git@github.com:utilisateur/projet.git

Git crea una cartella projet nella directory corrente, ci scarica tutta la cronologia e registra il repository remoto con il nome origin. Per scegliere un altro nome di cartella, aggiungilo come secondo argomento:

git clone git@github.com:utilisateur/projet.git mon-dossier

Verifica quello che hai ottenuto:

cd projet
git remote -v
git branch --show-current

origin	https://github.com/git/git.git (fetch)
origin	https://github.com/git/git.git (push)
master

Due osservazioni su questo output. origin compare due volte perché Git distingue l’indirizzo di lettura da quello di scrittura, quasi sempre identici. E qui il branch si chiama master perché è il nome del branch predefinito del repository clonato: il clone riprende il nome dal server e ignora completamente la tua impostazione init.defaultBranch, che riguarda solo i repository che crei tu.

Secondo caso: la cartella esiste, tu la pubblichi

È la situazione di chi ha iniziato a lavorare prima di pensare a Git. Posizionati nella cartella del progetto.

cd ~/projets/ma-boutique
git init

Initialized empty Git repository in /root/a2/.git/

Git ha appena creato una sottocartella .git che contiene tutta la cronologia. Cancellarla equivarrebbe a eliminare il versionamento, il resto dei tuoi file non viene toccato.

Registra poi un primo commit, altrimenti non c’è niente da pubblicare:

git add .
git commit -m "Premier commit"

Ora dichiara il repository remoto e fai push:

git remote add origin git@github.com:utilisateur/ma-boutique.git
git branch -M main
git push -u origin main

Queste tre righe meritano una spiegazione, perché vengono spesso copiate senza essere capite.

git remote add origin associa il nome breve origin all’URL del repository. origin non ha niente di magico, è una convenzione, potresti chiamarlo diversamente, ma nessuno lo fa.

git branch -M main rinomina il branch corrente in main. La -M maiuscola forza la rinomina anche se un branch main esiste già. Questa riga è inutile se hai impostato init.defaultBranch nel capitolo precedente, ma non fa alcun danno.

git push -u origin main invia il branch e, grazie a -u, memorizza il legame tra il tuo branch locale e quello del server. È questo legame che permette di scrivere poi solo git push e git pull. Senza, Git ti ferma:

fatal: No configured push destination.
Either specify the URL from the command-line or configure a remote repository using

    git remote add <name> <url>

and then push using the remote name

    git push <name>

To push to multiple remotes at once, configure a remote group using

    git config remotes.<groupname> "<remote1> <remote2>"

and then push using the group name

    git push <groupname>

Il tranello del README spuntato

Se hai creato il repository remoto con un README mentre la tua cartella locale aveva già dei commit, i due lati hanno ciascuno il proprio primo commit, senza alcun antenato comune. Git rifiuta allora di unirli:

fatal: refusing to merge unrelated histories

La soluzione è chiederglielo esplicitamente, una volta sola:

git pull origin main --allow-unrelated-histories

Merge made by the 'ort' strategy.
 README.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Le due cronologie vengono riunite da un commit di merge e il README raggiunge i tuoi file. Dopodiché puoi fare push normalmente.

Gestire i repository remoti

Qualche comando da conoscere per il seguito.

git remote -v                                    # elencare i repository remoti
git remote set-url origin git@github.com:u/p.git # cambiare l'URL, per esempio passare da HTTPS a SSH
git remote rename origin upstream                # rinominare
git remote remove origin                         # scollegare

git remote set-url è il comando da ricordare: è quello che sistema un repository clonato in HTTPS quando vuoi passarlo a SSH, senza doverlo riclonare.

Un repository locale può vivere senza server

Niente ti obbliga a pubblicare. Un git init seguito da qualche commit funziona benissimo su una cartella che non lascerà mai la tua macchina, e hai già la cronologia e la possibilità di tornare indietro. Il repository remoto aggiunge tre cose: un backup altrove che sul tuo disco, un punto di condivisione con gli altri e l’accesso agli strumenti dell’host.

Il tuo progetto è pronto. Il capitolo successivo passa ai comandi del lavoro quotidiano e al modo di annullare un errore.