Comando Git Clone: dall'uso di base alle tecniche avanzate

URL e protocolli Git

Come visto nell’esempio sopra di clonazione del repository “aws-cli”, per clonare un repository usando git clone, dobbiamo fornire la posizione del repository remoto, tramite un URL Git. 

Git supporta più protocolli per accedere ai repository remoti, ciascuno con la propria struttura, il proprio modello di sicurezza e casi d’uso consigliati. Capire i diversi tipi di URL Git e quando usare ciascuno può aiutarti a lavorare in modo più sicuro ed efficiente, soprattutto collaborando tra team o automatizzando i deploy.

Tipi di URL Git

Quando cloni un repository, l’URL che fornisci indica a Git come connettersi al server remoto. I tipi di URL Git più comuni sono:

HTTPS

Hyper Text Transfer Protocol Secure (HTTPS). Usato più comunemente per accedere alle pagine web tramite browser. Questo tipo di URL è semplice da usare e non richiede alcuna configurazione quando si clona un repository pubblico. Ecco alcuni esempi:

git clone https://github.com/<username>/<repo>.git
git clone https://github.com/aws/aws-cli.git
git clone https://gitlab.com/gitlab-org/gitlab.gitOfferto da

Analisi della struttura:

• https:// – Protocollo usato per la comunicazione (sicuro e compatibile con i firewall).
• github.com – Dominio del servizio di hosting Git.
• username/repo.git – Percorso del repository:
• username è il proprietario (utente o organizzazione)
• repo.git è il nome del repository Git

SSH

Secure Shell (SSH). Un protocollo di rete autenticato che richiede di stabilire le credenziali con il server di hosting prima di connettersi. Richiede la generazione di una coppia di chiavi SSH e l’aggiunta della chiave pubblica al tuo provider Git (ad es., GitHub, GitLab)

git clone [email protected]:<username>/<repo>.git
git clone [email protected]:aws/aws-cli.git
git clone [email protected]:gitlab-org/gitlab.gitOfferto da

Analisi della struttura:

• git@ – Specifica l’account utente SSH (di solito solo git).
• github.com: – Dominio del server Git, seguito da due punti : (non da uno slash).
• username/repo.git – Percorso del repository sul server.

Non avendo configurato alcuna chiave SSH sul mio account GitHub, viene mostrato il seguente messaggio quando provo a copiare l’URL SSH.

Nessuna chiave SSH configurata

Tratterò la configurazione delle chiavi SSH nella prossima sezione.

GIT

Un protocollo leggero e non autenticato per l’accesso in sola lettura. È un protocollo specifico di git. Oggi è raramente usato a causa di problemi di sicurezza e della dismissione da parte dei principali provider come GitHub e GitLab. Non troverai nemmeno l’opzione per clonare usando il protocollo git su GitHub o GitLab.

# Not recommended
git clone git://github.com/<username>/<repo>.gitOfferto da

Analisi della struttura:

• git// – Protocollo Git (sola lettura, non autenticato).
• github.com: – Dominio del server Git.
• username/repo.git – Percorso del repository sul server.

Indipendentemente dal protocollo usato per la clonazione, puoi verificare l’URL e il protocollo usati eseguendo i seguenti comandi:

git remote -v
git remote show originOfferto da

Scegliere il protocollo di URL giusto

Ogni protocollo ha dei compromessi. Con la seguente tabella, confrontiamo pro e contro per scegliere il protocollo più adatto al tuo caso d’uso.

Procedure di clonazione specifiche per protocollo

Una volta scelto un protocollo URL Git, il processo di clonazione e il flusso di autenticazione differiscono. Anche se entrambi i metodi raggiungono lo stesso obiettivo (clonare un repository remoto sulla tua macchina locale), rispondono a preferenze di sicurezza, esigenze degli utenti e complessità di setup diverse. 

In questa sezione, tratterò la clonazione di un repository sia tramite HTTPS che tramite SSH, insieme a best practice, passaggi di configurazione e consigli per la risoluzione dei problemi per garantire un processo di clonazione sicuro e fluido.

Workflow di clonazione Git via HTTPS

Clonare un repository Git su HTTPS è il metodo più semplice, ideale per principianti e ambienti vincolati (come firewall aziendali o reti ristrette).

Per clonare un repository, aprilo e copia l’URL HTTPS. L’immagine seguente è tratta da GitHub. Sarà simile anche per il tuo provider Git.

Ottieni l’URL HTTPS di un repository su GitHub

Poi esegui il comando git clone nella destinazione (ad es., il tuo laptop o una pipeline CI/CD) in cui vuoi che il repository venga clonato.

git clone https://github.com/aws/aws-cli.gitOfferto da

Comando git clone di base

Per clonare un repository pubblico, come abbiamo fatto per “aws-cli”, non è richiesta autenticazione poiché il repository è pubblico. Finché hai git installato sul tuo sistema, puoi clonare subito il repo pubblico senza alcuna configurazione.

Se invece stai clonando un repository privato, è necessaria l’autenticazione. Puoi autenticarti tramite:

• Personal Access Token
• Passkey

Per dimostrare l’autenticazione tramite personal access token, ho avviato un server su AWS EC2 e installato Git. All’esecuzione del comando git clone su un repository privato, viene richiesto un nome utente e una password. Inserisci il tuo username GitHub come nome utente e il tuo personal access token come password.

Autenticazione HTTPS via username/password

A causa di politiche di sicurezza più stringenti, GitHub e altri provider ora richiedono un personal access token al posto della password.

 

Istruzioni per l’access token con URL HTTPS. Fonte: GitHub

Se non inserisci il tuo personal access token, incontrerai il seguente errore:

Il supporto per l’autenticazione con password è stato rimosso.

Per creare un personal access token, vai su Crea un token GitHub e segui le istruzioni: 

Crea un personal access token su GitHub

Per evitare di inserire il personal access token ogni volta che Git richiede l’autenticazione su HTTPS, puoi usare un credential helper per memorizzare in modo sicuro le tue credenziali. Un’opzione diffusa è Git Credential Manager. 

Su macOS, Git si integra perfettamente con il Portachiavi di macOS, che personalmente uso per archiviare le credenziali. Nel mio caso, mi autentico tramite passkey memorizzate nel Portachiavi, per un’esperienza sicura e senza attriti.

Visualizza il credential helper

Passkey su macOS

Per configurare una passkey, vai alle impostazioni di password e autenticazione di GitHub e segui le istruzioni.

Crea una passkey su GitHub

Sebbene GitHub consenta di creare un personal access token senza scadenza, la maggior parte delle organizzazioni applica politiche di sicurezza che richiedono token con data di scadenza. Ciò significa che se un token è usato in ambienti automatizzati, come pipeline CI/CD, e scade, la pipeline fallirà per errori di autenticazione. È essenziale rigenerare proattivamente il token prima della scadenza e aggiornarne l’utilizzo di conseguenza.

Senza controlli adeguati, gli sviluppatori possono creare e usare inavvertitamente più personal access token senza una documentazione o un tracciamento chiari. Questo può portare rapidamente a confusione su quale token venga usato e dove, rendendo più difficile la manutenzione e l’audit. Per una migliore igiene, si consiglia di mantenere l’uso dei token minimo, documentato e legato a casi d’uso specifici.

Metodologia di clonazione via SSH

SSH offre un metodo di autenticazione sicuro e persistente, particolarmente adatto a contributori abituali e utenti avanzati. Una volta configurato, permette di interagire con i repository senza richieste ripetute di credenziali.

Per configurare l’autenticazione SSH, dobbiamo prima generare una coppia di chiavi SSH, composta da una chiave pubblica e una privata.

# ed25519 specifies the key type
ssh-keygen -t ed25519 -C "[email protected]"Offerto da

Crea una coppia di chiavi SSH

Dato che ho già una chiave SSH esistente in ~/.ssh/id_ed25519, ho sovrascritto la directory predefinita in cui risiedono le chiavi. Ma se stai creando la chiave SSH per la prima volta sul tuo dispositivo, accetta la directory predefinita.

Vai a SSH and GPC keys in GitHub per configurare la tua chiave SSH.

Configura la chiave SSH su GitHub

Copia il contenuto della chiave pubblica nella sezione “Key”. Nel mio caso, è il contenuto di id_ed25519.pub.

Incolla il contenuto di id_ed25519.pub

SSH usa la crittografia a chiave pubblica/privata. Conserva la tua chiave privata al sicuro sulla tua macchina. A questo punto, sei pronto per clonare un repository, pubblico o privato, via SSH.

Dopo aver configurato correttamente SSH, selezionare l’URL SSH non mostra più il messaggio di avviso, come visto nella sezione “Tipi di URL Git” sopra.

Ottieni l’URL SSH di un repository su GitHub

Poiché la chiave privata SSH risiede sul mio dispositivo locale, mostrerò git clone tramite SSH in locale invece che sul server EC2.

git clone [email protected]:aws/aws-cli.gitOfferto da

Clona repository pubblici e privati tramite SSH

Abbiamo eseguito con successo l’operazione di git clone usando SSH!

I vantaggi di SSH includono la sicurezza e l’ampio utilizzo nelle organizzazioni, poiché abilita l’autenticazione senza password, ideale per interazioni frequenti. Le connessioni SSH sono anche resistenti alle interruzioni di rete e spesso più rapide di HTTPS su lunghe distanze.

Tuttavia, è comune che gli sviluppatori incontrino problemi durante la configurazione delle chiavi SSH copiando la chiave pubblica sbagliata sul provider Git. Se hai più chiavi private per scopi diversi, devi definire nel file ~/.ssh/config quale chiave usare per ciascun host. Altrimenti, autenticandoti su GitHub, potrebbe essere usata la chiave privata destinata a Bitbucket, con conseguente errore di autenticazione.

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519Offerto da

Per testare la connettività e verificare la chiave in uso:

Verifica la connettività SSH

Esempi di utilizzo di git clone

Gli esempi di git clone visti finora coprono le funzionalità di base offerte dal comando. 

In questa sezione, ti guiderò tra le varie opzioni del comando, che ti permettono di adattare il processo di clonazione di un repository alla tua macchina locale. Che tu stia lavorando con branch specifici o ottimizzando per la velocità, capire queste varianti ti aiuterà a usare git clone in modo più efficace.

Clonazione di base del repository

L'uso più semplice di git clone, come abbiamo visto, consiste nel clonare un repository remoto sulla tua macchina locale.

# HTTPS protocol
git clone https://github.com/aws/aws-cli.git

# SSH protocol
git clone [email protected]:aws/aws-cli.gitOfferto da

Questi comandi creano una cartella chiamata “aws-cli” e inizializzano al suo interno una copia locale del repository, completa di cronologia delle versioni e configurazione del tracciamento del remoto.

Clonazione in una cartella specifica

Per impostazione predefinita, git clone crea una directory con il nome del repo. Per specificare un nome diverso per la directory di destinazione, passalo semplicemente come secondo argomento. 

Questo clona il contenuto di aws-cli.git nella cartella locale chiamata my-project-folder:

git clone https://github.com/aws/aws-cli.git my-project-folderOfferto da

Clonazione in una cartella specifica

Clonazione di un branch o tag specifico

Usa il flag --branch (o -b) per fare il checkout al branch specificato dopo aver clonato tutti i branch dal remoto. Il branch indicato diventa la “HEAD” in checkout, con gli altri branch disponibili localmente per il checkout.

Usando come esempio il repository “aws-cli”, il branch predefinito è develop. Proviamo invece a clonare e fare checkout del branch master.

# Clone a branch
git clone --branch master https://github.com/aws/aws-cli.gitOfferto da

Clonazione di un branch specifico

Possiamo anche clonare un tag specifico: 

# Clone a tag (read-only snapshot)
git clone --branch 2.27.43 https://github.com/aws/aws-cli.gitOfferto da

Clonazione di un tag specifico

Questo flag è utile quando lavori su una versione specifica o su un branch legato all'ambiente (ad es., staging, hotfix o release).

Shallow clone (profondità limitata)

Se ti serve solo l'ultima versione del progetto senza l'intera cronologia dei commit, usa il flag --depth per eseguire uno shallow clone. Il flag --depth specifica quanti commit vuoi clonare.

# Download only the latest commit history
git clone --depth 1 https://github.com/aws/aws-cli.gitOfferto da

Shallow clone

Questo velocizza il processo di clonazione e riduce l'uso di disco: è l'ideale per pipeline CI/CD o quando non ti interessa la cronologia dei commit. È particolarmente utile per il repository “aws-cli” che abbiamo clonato: avendo una lunga storia di commit, la differenza di tempo includendo il flag --depth è enorme.

Differenza di tempo con e senza shallow clone

Omettere la cronologia dei commit tranne l'ultimo ha aiutato a ridurre la quantità di informazioni da scaricare e, di conseguenza, il tempo necessario.

Configurazioni avanzate di clonazione

Sebbene il comando git clone sia usato più spesso nella sua forma base, Git offre diverse opzioni avanzate che forniscono maggiore controllo, efficienza e personalizzazione durante la clonazione. 

Queste funzionalità sono particolarmente utili quando si lavora con repository di grandi dimensioni, si gestiscono repository a livello di infrastruttura o si ottimizza per specifici flussi di sviluppo. 

In questa sezione, esploreremo operazioni specifiche per branch, clone shallow e parziali, specializzazioni di repository e configurazioni di clonazione granulari che potenziano sia gli sviluppatori sia i DevOps engineer.

Operazioni di clonazione specifiche per branch

Per impostazione predefinita, git clone recupera tutti i branch e fa il checkout di quello predefinito. Tuttavia, quando lavori con repository grandi o contribuisci a una specifica feature, spesso è più efficiente clonare un solo branch. Questo si ottiene con il flag --single-branch.

git clone --branch <branch-name> --single-branch <repo-url>
git clone --branch feature/cliq --single-branch https://github.com/aws/aws-cli.gitOfferto da

Clona un branch specifico

I vantaggi includono dimensioni e tempi di download ridotti, setup più rapido per uno sviluppo focalizzato su una feature e l'evitare cronologie di branch non necessarie.

Questo approccio è ideale quando vuoi lavorare su un branch di release o evitare di scaricare tutti i branch in repository CI/CD attivi. Se il nome del branch non è specificato nel comando, Git clonerà solo il branch predefinito.

Per capire meglio come clonare un branch specifico, dai un'occhiata al tutorial Git Clone Branch.

Tipi di repository specializzati

Quando cloniamo un repository, vengono clonati due componenti: il repository (.git folder) e la working directory. La working directory è comunemente chiamata anche working copy, work tree o workspace.

Differenza tra working directory e repository

Il contenuto della cartella .git è il seguente:

Contenuto della cartella .git

Questo ci porta all'argomento dei repository bare.

Repository bare

Un repository bare contiene solo la cartella .git e nessuna working directory.

git clone --bare <repo-url>
git clone --bare https://github.com/aws/aws-cli.gitOfferto da

Clonazione di un repository bare

Da quanto sopra, possiamo vedere che i contenuti clonati usando il flag --bare sono semplicemente quelli presenti nella cartella .git del repository non bare. Trattandosi di un repository bare, non c'è una working directory, il che significa che non possiamo eseguire i comandi git, come mostrato nell'immagine seguente:

L'operazione deve essere eseguita in una work tree

I repository bare sono in genere usati come repository centrali in un ambiente condiviso per la collaborazione o il mirroring, più che per lo sviluppo attivo. Per dimostrare la clonazione da un repository bare, userò il repository bare “aws-cli” che ho in locale.

Clona dal mio repository bare locale

Possiamo vedere che questo repository “aws-cli-non-bare” contiene la working directory. Esegui git remote -v per verificare che faccia riferimento al repository bare.

Repository mirror

Il comando git clone --mirror imposta un mirror del repository sorgente. Il flag  --mirror implica --bare, quindi anche il repository mirror non contiene una working directory. 

git clone --mirror <repo-url>
git clone --mirror https://github.com/aws/aws-cli.gitOfferto da

Clona un repository (centrale) per creare un repository mirror

Tuttavia, rispetto a --bare, --mirror non solo mappa i branch locali della sorgente ai branch locali della destinazione, ma mappa tutte le ref (incluse remote-tracking branch, note, ecc.) e configura una refspec tale che un git remote update nel repository di destinazione sovrascrive tutte queste ref. Questo fornisce una copia più completa, incluse tutte le referenze (branch, tag, ecc.).

Puoi fare riferimento alla documentazione GitHub per i passaggi completi per creare un mirror di un repository.

Mirroring di un repository in un'altra posizione. Fonte: GitHub

Filtri per clone parziale e riduzione delle dimensioni

I clone parziali consentono di recuperare solo un sottoinsieme degli oggetti del repository usando il flag --filter, risultando adatti a sviluppatori che hanno bisogno solo di una parte del codice, soprattutto in ambienti con vincoli di banda o spazio su disco. Alcuni esempi comuni del flag --filter sono:

• --filter=blob:none: salta il contenuto dei file (blob)
• --filter=blob:limit=<size>: esclude i file di una certa dimensione in su
• --filter=tree:<depth>: omette tutti i blob e gli alberi la cui profondità rispetto alla root è maggiore o uguale alla profondità definita.

blob:none

Il flag --filter=blob:none viene usato per ottimizzare le operazioni di clonazione evitando il download immediato del contenuto dei file (blob). 

# Binary Large Objects (BLOB)
git clone --filter=blob:none <repo-url>
git clone --filter=blob:none https://github.com/aws/aws-cli.gitOfferto da

Clonazione con filter=blob:none

Questo è particolarmente utile in repository grandi o quando serve solo un sottoinsieme del progetto. Ad esempio, nei monorepo, non tutti i team o gli sviluppatori hanno bisogno dell'intero codebase. 

Un frontend engineer che lavora solo in frontend/ non ha bisogno dei servizi backend o delle librerie condivise. Usare il flag --filter velocizza la clonazione e riduce lo storage rinviando il download dei blob finché non servono (ad es., quando si apre il file). L'immagine seguente mostra cosa fa Git in background quando apro un file, scaricando il blob del file on demand.

Git scarica il blob del file on demand

Un altro esempio è nelle pipeline CI/CD. Spesso le pipeline non hanno bisogno dell'intera cronologia del repo o di tutti i file. Combinato con lo sparse-checkout, --filter=blob:none consente alla pipeline di clonare solo le directory rilevanti (ad es., script di deployment).

blob:limit=<size>

Il flag --filter=blob:limit=<size> è utile per gli sviluppatori che vogliono evitare di scaricare file di grandi dimensioni (blob) durante la clonazione, pur recuperando subito i file più piccoli. Fa parte della funzionalità di clone parziale di Git ed è particolarmente utile quando si lavora con repository che contengono contenuti di dimensioni miste.

Per esempio, in alcuni progetti, specialmente quelli che usano Git LFS o con asset multimediali versionati (ad es., video, grandi dataset, asset di gioco), gli sviluppatori possono voler saltare i file grandi durante la clonazione, accelerando così il clone iniziale e rinviando il download dei file pesanti finché non sono necessari esplicitamente.

# Binary Large Objects (BLOB)
git clone --filter=blob:limit=<size> <repo-url>
#  The suffixes k, m, and g can be used to name units in KiB, MiB, or GiB
git clone --filter=blob:limit=<n>[kmg] <repo-url>
git clone --filter=blob:limit=1m https://github.com/aws/aws-cli.gitOfferto da

Clonazione con filter=blob:limit

tree:<depth>

Il flag --filter=tree:<depth> serve a limitare la profondità della struttura di directory per cui Git recupera gli oggetti tree durante un clone, aiutando a ridurre la dimensione del trasferimento dati; è particolarmente utile con progetti profondamente annidati come i monorepo. Ad esempio, se vuoi ispezionare rapidamente la struttura di un grande monorepo, per auditing, onboarding o revisione, scaricare alberi profondi è uno spreco.

git clone --filter=tree:<depth> <repo-url>
git clone --filter=tree:0 https://github.com/aws/aws-cli.gitOfferto da

Clonazione con filter=tree

Nota che il server Git da cui stai clonando (in questo caso, GitHub) potrebbe supportare solo alcuni valori per la profondità del filtro tree.

Il filtro tree consente profondità massima 0

Configurazione specifica della clonazione

Git fornisce diverse opzioni per personalizzare il comportamento durante la clonazione:

• --origin <name>: imposta un nome personalizzato per il remoto al posto di origin
• --template <dir>: usa una directory di template per l'inizializzazione della cartella .git iniziale
• --single-branch: evita di recuperare gli altri branch
• --recurse-submodules: inizializza e clona automaticamente i submodule

Queste opzioni sono utili quando si impostano ambienti standardizzati, si lavora con repository modulari o si integra con strumenti di deployment.

origin

Il flag --origin <name> permette agli sviluppatori di personalizzare il nome del remoto da cui viene clonato il repository. Per impostazione predefinita, Git chiama il remoto origin, ma questo flag consente di cambiarlo durante l'operazione di clone.

git clone --origin <remote name> <repo-url>
# Name the remote as “upstream”
git clone --origin upstream https://github.com/aws/aws-cli.gitOfferto da

Rinomina il remoto da origin a upstream

Gli sviluppatori potrebbero voler cambiare il nome del remoto per chiarezza, poiché in seguito potrebbero dover aggiungerne un altro (ad es., upstream vs. origin del fork). Cambiare il nome del primo remoto aiuta a evitare confusione e conflitti.

template

Il flag --template consente agli sviluppatori di specificare una directory di template personalizzata che Git userà quando crea la directory .git nel repository appena clonato. Le directory di template permettono di predefinire hook, file di configurazione o strutture di directory applicati automaticamente al repository durante l'inizializzazione.

# Specify the directory from which templates will be used
git clone --template=<template-directory> <repo>
git clone --template=./git-template https://github.com/aws/aws-cli.gitOfferto da

Uso del flag --template

Approfondirò il flag template nella sezione “Applicazione della directory template”.

single-branch

Il flag --single-branch serve a clonare solo la cronologia del branch specificato, invece di tutti i branch del repository remoto. Questo può ridurre significativamente la quantità di dati clonati, soprattutto in repository con molti branch longevi o una lunga cronologia di commit.

Quando ti assegnano di lavorare su un branch di feature o di release specifico (ad es., feature/login-ui, release/v2.0), non serve clonare la cronologia di altri branch non correlati.

git clone --branch feature/login-ui --single-branch <repo-url>

# If you do not specify a branch, Git will clone only the remote's default branch, usually main or master
git clone --single-branch <repo-url>
git clone --single-branch https://github.com/aws/aws-cli.gitOfferto da

Un tipico git clone traccia tutti i branch remoti, come mostrato nell'output di git branch -r qui sotto.

Tutti i branch remoti sono tracciati

Mentre l'aggiunta di --single-branch clona solo la cronologia del branch specificato.

Viene tracciato solo il branch predefinito

recurse-submodules

I submodule Git sono un riferimento a un altro repository, fissato a uno specifico commit. Ti permette di mantenere l'altro repository Git come sottodirectory del tuo repository, spesso usato per includere codice di terze parti, librerie condivise o componenti di vendor. 

Ho creato un repository pubblico su GitHub per dimostrare questo concetto.

Dimostrazione dei submodule

Quando cloni un progetto che contiene un submodule, per impostazione predefinita ottieni le directory che contengono i submodule, ma non i file al loro interno.

Cartella del submodule vuota

Invece di eseguire git submodule init per inizializzare il file di configurazione locale e git submodule update per recuperare tutti i dati di quel progetto, possiamo usare il flag --recurse-submodules con il comando git clone per inizializzare e clonare automaticamente tutti i submodule definiti nel file .gitmodules del repository.

git clone --recurse-submodules <repo-url>Offerto da

Clona i file all'interno della directory del submodule

Applicazione della directory template

Git consente di usare directory template per definire hook, configurazioni e altri file predefiniti durante la clonazione o l'inizializzazione del repository:

La struttura della directory template può essere simile a quella sotto, con hooks/pre-commit che contiene uno script di shell per bloccare i commit senza un ID JIRA e hooks/commit-msg che contiene il template per i messaggi di commit.

/home/devops/git-template/
├── config
├── description
├── hooks/
│   ├── pre-commit
│   └── commit-msg
├── info/
│   └── excludeOfferto da

Dopo aver definito i file necessari nella directory template, puoi usarla per le operazioni di git clone.

git clone --template=</path/to/template> <repo-url>
git clone --template=/home/devops/git-template https://github.com/aws/aws-cli.gitOfferto da

È ideale per:

• Applicare policy del repository tramite hook (ad es., pre-commit)
• Predefinire file di configurazione per CI/CD o strumenti
• Avviare progetti con una struttura comune

Le directory template semplificano i flussi di lavoro del team e garantiscono coerenza tra i repository clonati.

Clonare su diversi sistemi operativi

Sebbene il comando git clone funzioni allo stesso modo a livello core su tutte le piattaforme, l'esperienza può variare leggermente a seconda del sistema operativo. 

Considerazioni specifiche dell'ambiente—come strumenti di terminale, formati dei percorsi file e gestione dei permessi—possono influire su come gli sviluppatori interagiscono con Git. In questa sezione, ti mostrerò il processo di clonazione su Windows, Linux/Ubuntu e macOS per aiutarti a gestire eventuali particolarità.

Windows

Su Windows, gli sviluppatori usano tipicamente Git Bash, PowerShell o il Prompt dei comandi per eseguire i comandi Git. Possiamo installare Git dalla pagina dei download, che include Git Bash, una shell in stile Unix pensata per l'uso di Git su Windows.

git clone in Git Bash

git clone in PowerShell

Alcune considerazioni da tenere a mente:

• I percorsi file in Git Bash usano il formato in stile Unix (/c/Users/username/), mentre PowerShell e Prompt dei comandi usano il formato Windows (C:\Users\username\).
• Se usi PowerShell, assicurati che Git sia aggiunto al PATH di sistema.

Linux/Ubuntu

Le distribuzioni Linux come Ubuntu offrono un'esperienza Git fluida tramite il terminale nativo. Per l'esempio seguente, ho avviato un'istanza Ubuntu EC2 su AWS e mi sono connesso via SSH.

SSH nell'istanza Ubuntu EC2

Git era installato di default. In caso contrario sulla tua macchina, esegui semplicemente il comando sudo apt install git.

Installa git su Ubuntu

Vai nella directory desiderata ed esegui il comando git clone.

git clone in Ubuntu

Alcune considerazioni da tenere a mente:

• Assicurati che le chiavi SSH siano configurate correttamente per i repository privati (~/.ssh/id_rsa).
• I permessi dei file e la proprietà delle directory possono influire sulle operazioni del repository, soprattutto quando si clona in percorsi a livello di sistema.

Mac

macOS offre un ambiente basato su Unix che rispecchia da vicino Linux, rendendo le operazioni Git intuitive. Spesso Git è preinstallato. In caso contrario, l'installazione degli Xcode Command Line Tools (xcode-select --install) installerà anche Git.

Apri Terminale ed esegui il comando git clone.

git clone su Mac

Alcune considerazioni da tenere a mente:

• Come su Linux, la gestione delle chiavi SSH è importante per i repository privati.
• Gli utenti macOS usano spesso client GUI come GitHub Desktop o Sourcetree; assicurati che la configurazione di Git sottostante sia corretta.

Scenari pratici di implementazione

Sebbene git clone sia spesso usato semplicemente per ottenere una copia di un repository, la sua utilità va ben oltre nei flussi di lavoro ingegneristici reali. 

In questa sezione esamino come le strategie di clonazione possano essere applicate in scenari pratici, ognuno dei quali richiede un approccio su misura per massimizzare efficienza e coerenza.

Workflow di sviluppo enterprise

Nelle grandi organizzazioni, un cloning efficiente dei repository è fondamentale per semplificare l'onboarding degli sviluppatori e standardizzare la configurazione dei progetti. Si possono adottare le seguenti strategie:

• Per prima cosa, i cloni superficiali (--depth=1). Spesso usati per ridurre i tempi di setup per i nuovi sviluppatori che non hanno bisogno dell'intera cronologia dei commit.
• In secondo luogo, i repository template. Da non confondere con le directory template. I repository template contengono strutture di cartelle predefinite, hook e submodule da clonare per un avvio rapido del progetto. Su GitHub, puoi abilitare un repository come template andando nelle impostazioni.

Impostazione repository template

Dopo averlo abilitato, troverai il pulsante "Use this template" nella home page del tuo repository.

Usa il repository come template

• Infine, disporre di mirror interni di repository esterni riduce la dipendenza dalle reti pubbliche e accelera il cloning in ambienti sicuri.

Procedura di migrazione dei repository

Le organizzazioni possono migrare i repository tra piattaforme (ad es. da GitHub a GitLab) per vari motivi, tra cui sicurezza, conformità o considerazioni economiche. La migrazione richiederà un mirror clone per garantire una copia completa, inclusi tutti i branch, i tag e la cronologia dei commit.

Un processo tipico può essere il seguente:

# --mirror flag clones all refs and configuration.
git clone --mirror https://source-url.com/your-repo.git
cd your-repo.git
git push --mirror https://target-url.com/your-new-repo.gitOfferto da

Questo metodo preserva i metadati di Git meglio di un clone standard seguito da un push. Dopo la migrazione, aggiorna gli URL remoti e verifica le autorizzazioni di accesso.

Ottimizzazione della pipeline CI/CD

Negli ambienti automatizzati, ottimizzare le operazioni di clone fa risparmiare tempo e riduce l'uso di risorse, soprattutto in distribuzioni ad alta frequenza. Possiamo seguire le seguenti best practice per garantire un flusso di pipeline efficiente:

• Per prima cosa, usa cloni superficiali (--depth=1) per velocizzare l'avvio dei job.

git clone --depth 1 <repository-url>Offerto da

• In secondo luogo, clona solo il branch necessario per evitare ref superflue.

git clone --branch <branch-name> --single-branch <repo-url>Offerto da

• Infine, se più stage della tua pipeline CI/CD richiedono accesso agli stessi contenuti del repository, considera l'implementazione di un meccanismo di caching per evitare operazioni ripetute di git clone. Invece di clonare il repository in ogni stage, metti in cache la working directory dopo il checkout iniziale e passala come artefatto o volume condiviso agli stage successivi. 

Questo approccio riduce sensibilmente le operazioni ridondanti, accelera l'esecuzione della pipeline e conserva risorse di calcolo e rete.

Risoluzione dei problemi e diagnostica

Sebbene git clone sia un comando ampiamente usato e semplice, può capitare che gli sviluppatori incontrino problemi durante il processo di clonazione, specialmente in ambienti con controlli di autenticazione rigidi, configurazioni personalizzate dei repository o accesso di rete limitato. 

In questa sezione passerò in rassegna i problemi di clonazione più comuni e come risolverli in modo efficiente.

Risoluzione dei problemi di autenticazione

I fallimenti di autenticazione si verificano tipicamente quando si accede a repository privati o si usano credenziali scadute. A seconda del protocollo, HTTPS o SSH, si applicano messaggi di errore e correzioni differenti. Per ambienti con MFA abilitata, prediligi sempre SSH o HTTPS con PAT.

Con HTTPS, un errore comune è il fallimento dell'autenticazione. Questo può essere dovuto all'uso di un personal access token scaduto. Se l'MFA è abilitata, un'altra possibile causa è che il personal access token non sia stato usato come password.

Errore di autenticazione HTTPS

Con SSH, un errore comune è "Permission denied (publickey)". Questo può accadere perché la chiave pubblica non è stata aggiunta all'account del provider Git o perché la chiave privata salvata sul tuo dispositivo locale non si trova nella directory corretta.

Errore di autenticazione SSH

Puoi convalidare la connettività con:

ssh -T [email protected]Offerto da

Recupero degli oggetti in cloni parziali

Raramente, usando cloni parziali (--filter o flag --depth), potresti imbatterti in oggetti mancanti (ad es. "error: object <sha> is missing") se Git tenta di accedere a parti del repository non scaricate inizialmente. 

Personalmente non mi è mai capitato. Tuttavia, potresti riscontrare errori accedendo a commit storici, branch o tag. Se ciò avviene in una pipeline, gli strumenti di build o gli script potrebbero fallire. Puoi recuperare esplicitamente i dati mancanti usando:

# Have Git refetch all objects from the remote, even if it thinks it already has them.
# For dealing with a broken or corrupted partial clone
git fetch --filter=blob:none --refetch

# Convert a shallow clone into a full clone. Retrieves the rest of the commit history that was omitted during the shallow clone.
git fetch --unshallow

# Obtain a deeper history of the branch
git fetch origin <branch> --depth=50

# Fetches 30 more commits from the current branch’s history. Repeat as needed.
git fetch --deepen=30Offerto da

Fai riscaricare a Git tutti gli oggetti dal remote

Messaggi di errore comuni di git clone e soluzioni

Oltre ai problemi sopra che potresti incontrare durante git clone, la seguente tabella copre altri errori comuni.

Conclusione

Il comando git clone può sembrare semplice a prima vista e, per molti, l'uso di base è stato sufficiente. Tuttavia, come mostrato in questo articolo, è uno strumento fondamentale con applicazioni molto ampie. 

Abbiamo visto come funziona git clone, esplorato tipi di URL e protocolli, analizzato configurazioni avanzate e comportamenti specifici dei sistemi operativi, ed esaminato scenari reali come CI/CD, workflow enterprise e tecniche comuni di troubleshooting.

Adattare git clone al tuo ambiente—che si tratti di cloni superficiali nelle pipeline, migrazioni di repository o collaborazione su larga scala—può migliorare sensibilmente prestazioni ed efficienza del team. Poiché gli ambienti di sviluppo moderni sono sempre più complessi e distribuiti, padroneggiare queste configurazioni garantisce non solo di usare Git, ma di usarlo al meglio.

Guardando avanti, i meccanismi di clonazione di Git possono essere migliorati, ad esempio con cloni parziali più intelligenti, un supporto migliore per grandi monorepo e una gestione più intuitiva di submodule e filtri. Con l'evoluzione di Git, restare aggiornati su questi miglioramenti permetterà agli sviluppatori di lavorare più velocemente ed efficientemente su qualsiasi sistema o scala.

Per saperne di più su Git, ti consiglio diend prendere il corso Introduction to Git. Se vuoi portare le tue competenze al livello successivo, allora il corso Advanced Git fa per te!