Repository in Git: cos'è, quali tipi esistono e come funzionano

Cos'è un repository in Git

Repository Git — è una struttura dati in cui il sistema di controllo versione archivia metadati e oggetti che descrivono la cronologia delle modifiche dei file del progetto. Quando uno sviluppatore inizializza un repository con il comando git init, Git crea una cartella nascosta .git nella radice del progetto.

All'interno di questa cartella si trovano tutti gli oggetti, i riferimenti e i file di configurazione necessari per il funzionamento del sistema. Il repository non è legato a una posizione specifica — lo sviluppatore può crearlo localmente e poi collegarlo a un server remoto.

Git utilizza un modello di repository distribuito: ogni membro del progetto ha una copia completa della cronologia sul proprio computer. Ciò significa che la maggior parte delle operazioni — commit, visualizzazione della cronologia, creazione di branch — vengono eseguite localmente senza contattare il server.

Secondo la documentazione di Git, l'architettura distribuita rende il sistema tollerante ai guasti: se il server si guasta, qualsiasi repository locale può diventare una fonte per ripristinare l'intera cronologia del progetto.

Repository locale e remoto

Repository locale — è una copia del progetto sul computer dello sviluppatore. Contiene l'intera cronologia di commit, branch e tag e consente di eseguire operazioni di commit, branch, merge e rebase senza connessione di rete.

Repository remoto — è ospitato su un server e funge da punto di sincronizzazione per tutti i membri del team. Gli sviluppatori inviano le loro modifiche con il comando git push e recuperano le modifiche altrui con git pull.

La connessione tra repository locale e remoto viene configurata tramite remote origin — l'URL del server memorizzato nella configurazione di Git. Un repository locale può essere collegato a più repository remoti, il che è utile quando si lavora con i fork.

Il principale vantaggio di questo modello è che lo sviluppatore può lavorare sul codice offline e sincronizzare le modifiche solo quando è pronto per inviare il risultato.

Differenze tra repository locale e remoto

Come Git archivia i dati in un repository

Il modello di archiviazione di Git è fondamentalmente diverso dagli altri sistemi di controllo versione. Invece di archiviare un elenco di modifiche (delta) tra le versioni, Git conserva snapshot completi di tutti i file del progetto al momento di ogni commit.

Ogni oggetto nel repository è identificato da un hash SHA-1 univoco di 40 caratteri. Se il contenuto di un file non è cambiato tra i commit, Git non crea un nuovo oggetto ma riutilizza quello esistente — questo risparmia spazio.

Git utilizza quattro tipi di oggetti: blob (contenuto del file), tree (struttura della directory), commit (snapshot con metadati) e tag (riferimento nominato a un commit). Tutti gli oggetti sono archiviati nella cartella .git/objects.

Secondo Git Internals, il modello a oggetti di Git garantisce l'integrità dei dati: qualsiasi modifica al contenuto di un file genera un nuovo hash, rendendo impossibile modificare la cronologia senza essere scoperti.

Struttura della cartella .git

La cartella .git è il cuore del repository. Senza di essa, Git non può tracciare le modifiche e una directory ordinaria rimane solo un insieme di file. Comprendere la struttura di questa cartella aiuta a diagnosticare i problemi con il repository.

• objects/ — tutti gli oggetti del repository: blobs, trees, commits, tags. Archiviati in forma compressa.
• refs/ — riferimenti ai commit: heads (branch), tags (etichette), remotes (branch remoti).
• HEAD — file che punta al branch attivo o al commit corrente.
• config — impostazioni del repository: URL remoto, nome utente, email e altri parametri.
• index — area di staging dove Git memorizza le informazioni sui file preparati per il commit.
• logs/ — registri di aggiornamento dei riferimenti (reflog) che archiviano la cronologia degli spostamenti di HEAD e dei branch.

Il file HEAD merita un'attenzione particolare. In condizioni normali contiene un riferimento simbolico a un branch, ad esempio ref: refs/heads/main. In stato detached HEAD punta direttamente a un commit — ciò significa che i nuovi commit non saranno collegati a nessun branch.

Operazioni di base con il repository

Lavorare con un repository Git comporta una serie di operazioni di base che lo sviluppatore esegue quotidianamente. Ogni operazione modifica lo stato del repository aggiungendo nuovi oggetti o spostando riferimenti.

• git init — crea un nuovo repository vuoto nella directory corrente. Git crea la cartella .git con la struttura iniziale.
• git clone — copia un repository remoto esistente sulla macchina locale insieme all'intera cronologia dei commit.
• git add — aggiunge le modifiche dei file all'area di staging (indice), preparandole per il commit.
• git commit — crea uno snapshot del progetto basato sui dati dell'indice e lo salva come nuovo oggetto commit.
• git push — invia nuovi commit dal repository locale a quello remoto, aggiornando i branch sul server.
• git pull — recupera nuovi commit dal repository remoto e li unisce con il branch locale corrente.

Le operazioni push e pull sono le uniche che richiedono una connessione al server remoto. Tutte le altre operazioni vengono eseguite interamente in locale, garantendo velocità elevata anche con un grande volume di cronologia.

Ciclo di vita di un file nel repository

Ogni file nel repository attraversa quattro stati: untracked (non tracciato), modified (modificato), staged (preparato) e committed (committato). Git traccia solo i file che sono stati aggiunti esplicitamente tramite git add o che sono già nella cronologia dei commit.

Comprendere questo modello è la chiave per lavorare efficacemente con Git. Lo sviluppatore può preparare selettivamente solo una parte dei file modificati per il commit, creando commit logicamente completi con una descrizione chiara.

Piattaforme popolari per ospitare repository

I repository remoti sono solitamente ospitati su piattaforme specializzate che forniscono interfaccia web, sistema di controllo degli accessi e strumenti aggiuntivi per lo sviluppo collaborativo.

• GitHub — la piattaforma più grande con oltre 100 milioni di repository. Offre Actions, Pull Requests, Issues e Wiki. Gratuito per progetti pubblici.
• GitLab — piattaforma con CI/CD integrato, Container Registry e pipeline DevOps incorporata. Disponibile come SaaS e versione self-hosted.
• Bitbucket — soluzione Atlassian con integrazione Jira e Trello. Popolare negli ambienti aziendali grazie alle impostazioni di accesso flessibili.

La scelta della piattaforma dipende dalle dimensioni del team, dai requisiti di privacy e dalle integrazioni necessarie. Per lo sviluppo mobile, GitHub viene spesso scelto per l'ampio supporto della comunità e l'integrazione con gli strumenti CI/CD per iOS e Android.

Esempi di comandi per lavorare con un repository

Consideriamo uno scenario pratico: uno sviluppatore clona un repository esistente, crea un nuovo branch, apporta modifiche e le invia al server. Ogni comando dimostra il lavoro con diversi componenti del repository.

# Clonare un repository remoto
git clone https://github.com/user/mobile-app.git

# Navigare alla directory del progetto
cd mobile-app

# Creare un nuovo branch feature e passarvi
git checkout -b feature/auth

# Verificare lo stato dei file modificati
git status

# Aggiungere tutte le modifiche all'area di staging
git add .

# Creare un commit con descrizione
git commit -m "Add authentication module"

# Inviare le modifiche al repository remoto
git push origin feature/auth

Il comando git status è uno dei più utili nel lavoro quotidiano. Mostra quali file sono stati modificati, quali sono preparati per il commit e quali non sono affatto tracciati da Git.

Visualizzare la cronologia dei commit

Per analizzare la cronologia del repository, il comando git log viene utilizzato con vari flag di formattazione. Mostra la cronologia dei commit, i loro autori, le date e gli identificatori SHA-1.

# Visualizzare la cronologia con il grafico dei branch
git log --oneline --graph --all

# Visualizzare le modifiche in un commit specifico
git show a1b2c3d

# Confrontare lo stato attuale con l'ultimo commit
git diff HEAD

# Visualizzare la cronologia di un file specifico
git log --follow src/MainActivity.kt

Il flag --graph mostra un grafico ASCII dei rami, particolarmente utile nei repository con lavoro attivo su più branch. Per i progetti mobili con rilasci frequenti, un grafico visivo aiuta a valutare rapidamente la struttura dello sviluppo.