Git e controllo versione nello sviluppo mobile: cos'è, comandi di base e come funziona

Controllo versione e Git: cos'è?

Git è un sistema di controllo versione distribuito (VCS) creato da Linus Torvalds nel 2005 per lo sviluppo del kernel Linux. A differenza dei sistemi centralizzati (SVN, CVS), Git memorizza una copia completa della cronologia del progetto su ogni computer dello sviluppatore. Ciò significa che puoi eseguire commit, esplorare la cronologia e creare rami anche senza connessione Internet.

Git funziona con istantanee (snapshot) — ogni commit salva lo stato di tutti i file del progetto al momento del salvataggio. Se un file non è cambiato, Git crea un riferimento alla versione precedente, risparmiando spazio. Secondo l'analisi GitHub (2025), il repository medio contiene 1.200 commit e 15 rami.

In IT Sectr, usiamo Git dal 2017 in tutti i progetti. La nostra esperienza mostra che una corretta configurazione di Git dal primo giorno fa risparmiare al team fino al 30% del tempo in unione e risoluzione conflitti. Git è diventato lo standard de facto — è supportato da tutti gli IDE moderni (Android Studio, Xcode, VS Code) e sistemi CI/CD.

# Configurazione base di Git
git config --global user.name "Il Tuo Nome"
git config --global user.email "tua@email.com"

# Creazione di un nuovo repository
git init my-project
cd my-project

# Aggiunta file e commit
git add README.md
git commit -m "Initial commit"

# Lavorare con un repository remoto
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Il codice sopra mostra la sequenza base: inizializzare un repository, primo commit e pubblicazione su server remoto. Il comando git init crea una cartella nascosta .git che memorizzerà l'intera cronologia del progetto. Ogni git commit crea un punto di ripristino a cui puoi tornare in qualsiasi momento.

Concetti di base: Repository, Branch, Commit

Comprendere i tre concetti di base — Repository, Branch e Commit — è essenziale per lavorare con qualsiasi sistema di controllo versione. Un repository è un contenitore per l'intero progetto. Un commit è uno stato salvato dei file. Un branch è una linea di sviluppo separata.

Repository può essere locale (sul tuo computer) o remoto (su un server GitHub, GitLab). Ogni sviluppatore clona il repository remoto sulla propria macchina e lavora con una copia locale. Le modifiche vengono sincronizzate tramite push (inviare) e pull (recuperare). Nel controllo versione distribuito, ogni sviluppatore memorizza una copia completa della cronologia.

Branch (ramo) è un puntatore a uno dei commit. I rami consentono lo sviluppo parallelo: uno sviluppatore lavora su una nuova funzionalità (feature branch), un altro corregge un bug (hotfix branch), un terzo prepara un rilascio (release branch). Secondo GitLab Flow (2025), il progetto medio ha 3–5 rami attivi contemporaneamente.

Commit è un'unità di modifica. Ogni commit contiene un hash univoco (SHA-1), un messaggio, un autore e un timestamp. Una buona pratica è fare commit piccoli e significativi con messaggi descrittivi — questo semplifica il Code Review e il rollback delle modifiche. Il controllo versione tramite commit fornisce la cronologia completa del progetto.

Feature Branch

Feature Branch (ramo di funzionalità) è un ramo temporaneo creato da develop o main per sviluppare un'attività specifica. Dopo aver completato il lavoro, il ramo viene unito tramite Pull Request e cancellato. Questa pratica consente di isolare le modifiche senza compromettere la stabilità della base di codice principale.

Flusso di lavoro tipico: creare ramo feature/add-login → fare diversi commit → creare Pull Request → passare al Code Review → unire in develop. In IT Sectr usiamo esattamente questo approccio: ogni attività Jira corrisponde a un ramo feature separato. Ciò semplifica il tracciamento delle modifiche e il rollback se necessario.

Rebase vs Merge

Merge crea un commit di unione che combina due rami. Preserva la cronologia completa, incluse le linee di sviluppo parallelo. Rebase riscrive la cronologia: prende i commit da un ramo e li "riapplica" sopra un altro, creando una cronologia lineare.

Merge è più adatto per rami pubblici e team grandi dove la cronologia è importante. Rebase è comodo per rami feature personali prima di creare un PR — rende la cronologia più pulita e comprensibile. Tuttavia, rebase non dovrebbe mai essere applicato a rami su cui altri sviluppatori stanno lavorando, poiché riscrive la cronologia.

# Creare e passare a un ramo feature
git checkout -b feature/add-login main

# Lavorare nel ramo
git add login-screen/
git commit -m "Add login screen layout"

# Rebase sul main più recente prima del PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push nel repository remoto
git push origin feature/add-login

Questo esempio mostra un flusso di lavoro tipico: creare un ramo feature da main, diversi commit e rebase per ottenere una cronologia lineare pulita prima dell'invio per revisione. Questo approccio minimizza i conflitti di unione.

Git Flow vs Trunk-Based Development

Git Flow e Trunk-Based Development sono due principali strategie di controllo versione che determinano come un team organizza il lavoro con Git. La scelta dipende dalle dimensioni del team, dalla frequenza dei rilasci e dai requisiti di stabilità.

Git Flow è un modello rigoroso con più rami permanenti: main (codice di rilascio), develop (sviluppo corrente), feature/* (nuove funzionalità), release/* (preparazione rilascio) e hotfix/* (correzioni urgenti). Questo modello è buono per progetti con cicli di rilascio chiari (es. app mobili con versioni 1.0, 2.0).

Trunk-Based Development è un approccio con un singolo ramo principale (trunk/main) dove tutti gli sviluppatori uniscono le modifiche più volte al giorno. I feature flag vengono usati per nascondere funzionalità incomplete. Questo approccio è popolare nello sviluppo web e nelle startup dove la velocità di consegna è importante.

Git Flow

Git Flow, proposto da Vincent Driessen nel 2010, rimane uno dei modelli più popolari. Il suo principale vantaggio è la separazione rigorosa del codice per fasi del ciclo di vita. Il ramo main contiene solo codice di rilascio, develop contiene lo sviluppo corrente e i rami feature isolano le nuove funzionalità l'una dall'altra.

I rami hotfix vengono creati da main per correzioni urgenti e dopo l'unione vengono uniti sia in main che in develop. I rami release vengono creati da develop quando il team è pronto per un rilascio. Vengono aggiunte solo correzioni di bug e metadati (versione, build). Dopo il rilascio, il ramo release viene unito in main e develop. Secondo un sondaggio JetBrains (2024), il 37% dei team usa Git Flow. Questo modello di controllo versione rimane lo standard per progetti con rilasci fissi.

# Esempio Git Flow: iniziare lavoro su un rilascio
git checkout -b release/1.2.0 develop

# Correggere bug nel ramo release
git commit -m "Fix login button crash"

# Completare il rilascio — unire in main e develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Eliminare il ramo release
git branch -d release/1.2.0

Il codice illustra la creazione di un ramo release, la sua stabilizzazione e l'unione nei rami principali. Il flag --no-ff garantisce un commit di unione, preservando l'informazione che le modifiche provengono dal ramo release.

Pull Request e Code Review

Pull Request (PR) è un meccanismo con cui uno sviluppatore propone modifiche dal proprio ramo al ramo principale. La PR è un elemento chiave del controllo versione nel lavoro di squadra — non è solo un modo per unire codice, ma un processo di discussione, revisione e controllo qualità. In GitLab, il meccanismo simile si chiama Merge Request (MR), ma l'essenza è la stessa: informare il team delle modifiche e ottenere approvazione.

Una buona PR dovrebbe essere piccola (fino a 300 righe di codice), focalizzata su un singolo compito e contenere una descrizione di cosa è stato fatto e perché. Secondo uno studio Google (2025), le PR oltre 400 righe richiedono il doppio del tempo per la revisione e la probabilità di rilevare bug diminuisce del 30%. Il Code Review è il controllo del codice da parte di un altro sviluppatore prima dell'unione.

In IT Sectr, pratichiamo il Code Review obbligatorio per ogni PR. Ciò non solo migliora la qualità del codice, ma aiuta anche a diffondere la conoscenza all'interno del team. Il Code Review verifica: se il codice segue i principi architetturali, se ci sono bug, se ci sono abbastanza test, se le variabili sono nominate correttamente. Tutti i commenti vengono discussi nella PR fino all'unione.

Piattaforme: GitHub, GitLab, Bitbucket

Git è un protocollo, ma per la collaborazione serve una piattaforma di controllo versione che fornisca interfaccia web, gestione accessi, CI/CD e strumenti di revisione. Tre piattaforme dominano il mercato: GitHub, GitLab e Bitbucket.

GitHub è la piattaforma più grande con oltre 56 milioni di sviluppatori. Di proprietà Microsoft, offre Actions (CI/CD), Pages (hosting), Discussions e Copilot. Il piano gratuito include repository privati illimitati per team fino a 3 persone. GitHub è popolare nella comunità open-source.

GitLab è una piattaforma DevOps completa con CI/CD integrato, registro container e gestione infrastruttura. A differenza di GitHub, GitLab può essere installato sul proprio server (Self-Managed). Bitbucket di Atlassian è strettamente integrato con Jira e Confluence, rendendolo la scelta per team che già usano l'ecosistema Atlassian.