Git per Sviluppatori — Dalle Basi ai Workflow Team per Codice Senza Conflitti

Cos'è Git e Perché Ogni Sviluppatore Dovrebbe Usarlo?

Se non usi Git, stai lavorando con una copia di cartelle chiamate "finale_v2_ok_definitivo.zip". Lo vediamo ogni giorno nei progetti che ci arrivano: sviluppatori che perdono ore a ricostruire versioni, che sovrascrivono file, che licenziano codice funzionante per errore. Git non è un lusso — è la base minima per non sprecare tempo e soldi.

Noi, di Meteora Web, usiamo Git su ogni progetto, dal tema WordPress su misura alla piattaforma Laravel complessa. Non perché sia di moda, ma perché permette di lavorare in team senza pestarsi i piedi e di tornare indietro quando qualcosa si rompe. Un cliente ci ha chiamati perché il suo sito era sparito dopo un aggiornamento manuale. Con Git avremmo fatto un git revert in 10 secondi. Senza, abbiamo dovuto recuperare un backup di due giorni prima.

Git tiene traccia di ogni modifica al codice. Ogni commit è uno snapshot del tuo lavoro. Puoi creare rami (branch) per sperimentare senza rischi. Puoi unire (merge) il lavoro di più persone. E se sbagli, torni indietro con un comando.

Azioni immediate: Se non hai Git, installalo da git-scm.com. Avvia un repository locale con git init, fai il primo commit con git add . && git commit -m "Primo commit". Fatto? Hai appena iniziato a proteggere il tuo codice.

Come Funziona il Branching in Git e Come Gestire i Conflitti?

Il branching è il superpotere di Git. Un branch è un puntatore a un commit. Quando crei un nuovo branch, stai creando una copia del progetto in cui lavorare senza toccare la versione stabile (main). Questo permette di sviluppare feature, testare idee, correggere bug in isolamento.

Creare un branch: git branch feature-xyz lo crea, git checkout feature-xyz ci si sposta (oppure git checkout -b feature-xyz in un colpo solo).

Unire i branch: git merge feature-xyz (stando sul branch di destinazione). Qui arrivano i conflitti: se due sviluppatori modificano la stessa riga, Git non sa quale tenere. Pazienza: Git ti segnala i file in conflitto, li apri, cerchi le sezioni <<<<<<<, scegli la versione corretta, salvi e fai git add del file risolto, poi git commit.

Noi consigliamo di mantenere i branch piccoli e di fare merge frequenti. Più a lungo un branch rimane separato, più conflitti accumula. Un errore comune: lavorare per settimane su un branch e poi trovarsi con centinaia di conflitti. Il rimedio? Fai rebase o merge del branch main ogni giorno nel tuo branch di lavoro.

Azioni immediate: Prova: crea un branch, modifica un file, fai commit, torna su main, unisci con git merge. Simula un conflitto modificando la stessa riga su entrambi i branch e risolvilo manualmente. È il modo migliore per imparare.

Git Rebase vs Merge: Quando Usare l'Uno e Quando l'Altro?

git rebase e git merge fanno la stessa cosa — uniscono due branch — ma in modo diverso. Merge crea un nuovo commit di unione (merge commit) che tiene traccia della storia. Rebase riscrive la storia: prende i tuoi commit e li applica in cima al branch di destinazione, come se avessi lavorato direttamente su di esso.

Quando usare merge? Su branch pubblici (come main o release) dove la cronologia lineare è meno importante della tracciabilità. Merge commit mostra chiaramente dove un branch è stato integrato. Lo usiamo per unire feature branch in develop.

Quando usare rebase? Su branch personali o non ancora condivisi. Rebase rende la cronologia pulita e lineare, evitando il "grafico a spaghetti". Però mai fare rebase su branch pubblici: riscrivere la storia condivisa crea caos per gli altri sviluppatori.

In pratica, nel nostro workflow: git merge --no-ff per unire feature in main (conserva il contesto), e git rebase main periodicamente sul feature branch per mantenere tutto aggiornato.

Azioni immediate: Sperimenta su un repository di test: crea due branch, fai alcuni commit su entrambi, poi prova merge e poi reset e prova rebase. Osserva la differenza nel log (git log --graph --oneline).

Come Usare Git Stash per Salvare Lavoro Temporaneo?

Sei in mezzo a una modifica non finita e devi passare a un altro branch per un bug urgente. Non vuoi committare codice rotto. git stash salva lo stato corrente e riporta il working directory pulito. Puoi recuperarlo dopo con git stash pop.

Noi usiamo stash continuamente: per cambiare rapidamente contesto, per testare una soluzione alternativa senza perdere il lavoro in corso, per sperimentare senza sporcare la cronologia. Puoi anche creare più stash (git stash list) e applicare quello giusto (git stash apply stash@{2}).

Attenzione: Stash non segue file non tracciati (new file) a meno che non usi git stash -u. E se dimentichi di applicare uno stash, dopo giorni potresti perderlo. Noi consigliamo di usare stash solo per salvataggi temporanei di pochi minuti/ore, non per lavoro a lungo termine. Per quello, meglio creare un branch temporaneo.

Azioni immediate: Simula: modifica un file, fai git stash, passa a un altro branch, torna indietro, git stash pop. Vedrai le modifiche ripristinate.

Come Organizzare il Workflow con Pull Request e Code Review su GitHub?

Git da solo non basta per il lavoro di squadra. Serve un processo. Le pull request (PR) su GitHub (o GitLab, Bitbucket) sono il modo standard per proporre modifiche. Non si fa push diretto su main: si crea un branch, si lavora, si apre una PR, i colleghi fanno review, si approva e si merge.

Noi usiamo le PR da anni. Abbiamo visto team che saltano la review e poi passano ore a debuggare errori evitabili. La review non è un controllo di polizia: è un'occasione per condividere conoscenza e migliorare la qualità. Il codice scritto da una persona sola ha buchi; due paia di occhi li vedono.

Proteggere il branch main: Su GitHub, attiva le branch protection rules: richiedi almeno una review, blocca il push diretto, richiedi che i test passino prima del merge. Così il main rimane sempre stabile.

Azioni immediate: Se lavori da solo, usa comunque le PR su un repository remoto. È un'abitudine che ti prepara al lavoro di squadra. Crea un branch, fai push, apri PR su te stesso, fai review, approva e mergia. Imparerai il flusso.

Come Automatizzare la Qualità del Codice con Git Hooks?

Git hooks sono script che si attivano su eventi come pre-commit, pre-push, post-merge. Possono eseguire linter, test, formattazione, analisi di sicurezza. Noi li usiamo per impedire di committare codice non formattato o con errori di sintassi.

Esempio pratico: Abbiamo un progetto PHP con Laravel. Un hook pre-commit esegue php -l su ogni file PHP modificato e ./vendor/bin/phpcs con PSR-12. Se ci sono errori, il commit viene bloccato. Così il repository resta pulito e il team segue lo standard senza sforzo.

Gli hook sono locali (non si condividono con git push) a meno di non usarli con un tool come husky (JS) o pre-commit (Python). Per progetti seri, consigliamo di versionare un file di configurazione e usare un framework di hook per sincronizzarli tra tutti gli sviluppatori.

Azioni immediate: Crea un hook semplice: nella cartella .git/hooks del tuo repository, rinomina pre-commit.sample in pre-commit e scrivi uno script bash che esegue npm run lint. Rendi eseguibile chmod +x .git/hooks/pre-commit. Prova a committare codice non allineato: verrà bloccato.

Come Trovare un Bug con Git Bisect e Git Blame?

Un bug si è introdotto da qualche parte. Dove? git bisect fa una ricerca binaria tra i commit per trovare esattamente quello che ha rotto tutto. git blame mostra chi ha modificato l'ultima volta ogni riga di un file.

Li usiamo spesso quando un cliente ci segnala un malfunzionamento dopo un aggiornamento. Con git bisect si parte da un commit buono (sai che funzionava) e uno cattivo (quello rotto), poi Git fa il checkout di commit intermedi, tu testi e segni good/bad. Dopo pochi passi, hai il colpevole.

git blame invece è immediato: git blame app/Http/Controllers/OrderController.php mostra per ogni riga il commit, l'autore e la data. Utile per capire perché una riga è stata scritta e da chi, magari per chiedere chiarimenti.

Azioni immediate: In un repository con storia, identifica un bug noto e usa git bisect per trovare il commit che lo ha introdotto. La pratica rende veloci: in 3-4 passi puoi isolare un problema che altrimenti richiederebbe ore di ricerca manuale.

Gitflow vs Trunk-Based: Quale Strategia di Branching per il Tuo Team?

Gitflow è un modello classico: branch main, develop, feature, release, hotfix. È strutturato e prevedibile, adatto a team che rilasciano a scadenze fisse e hanno ambienti separati. Noi lo usiamo per progetti con cicli di rilascio mensili e clienti che richiedono stabilità.

Trunk-based development (TBD) è più snello: tutti lavorano su branch corti che mergiano su main più volte al giorno. Si basano su feature flag per disabilitare codice incompleto in produzione. È adatto a team che vogliono rilasci continui, CI/CD maturo e disciplina.

La scelta dipende dal contesto. Per una PMI che deve rilasciare rapidamente un e-commerce, TBD è eccessivo. Per un SaaS con deploy multipli al giorno, Gitflow rallenta. Noi consigliamo di iniziare con un modello semplice: un branch main e branch feature. Crescendo, si possono aggiungere regole senza esagerare.

Azioni immediate: Valuta il tuo team: quante persone? Quanto spesso rilasciate? Se lavori da solo o in 2-3, non serve Gitflow. Tieni solo main e branch temporanei. Il processo complesso viene dopo.

Come Impostare una Pipeline CI/CD con GitHub Actions?

GitHub Actions automatizza test, build, deploy. Quando fai push su un branch o PR, si esegue un workflow definito in YAML dentro .github/workflows. Noi lo usiamo per eseguire PHPUnit, compilare asset, e deploy automatico su server.

Esempio minimo:

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: vendor/bin/phpunit

Questo workflow esegue i test a ogni push o PR su main. Se i test falliscono, il merge è bloccato. Puoi estendere per deploy su FTP, SSH, o servizi cloud. Noi abbiamo un workflow che dopo test passa a deploy via RSync su server di produzione, solo se il branch è main e i test passano.

Attenzione alla sicurezza: Non hardcodare credenziali. Usa i secret di GitHub: ${{ secrets.SSH_KEY }}.

Azioni immediate: Crea un file .github/workflows/ci.yml nel tuo repository. Aggiungi un semplice test (es. esegui un comando echo). Fai push e vedi l'azione eseguirsi nella scheda Actions su GitHub.

Come Gestire un Monorepo con Git?

Un monorepo contiene più progetti in un unico repository. Vantaggi: condivisione di codice, refactoring su tutto il progetto, build unificata. Svantaggi: dimensione, storia confusa, permessi complessi. Noi gestiamo un monorepo per la nostra piattaforma di gestione social: frontend Vue, backend Laravel, pacchetti condivisi. Tutto in un repo.

Git supporta monorepo nativamente, ma servono accorgimenti: git sparse checkout per clonare solo parti, git submodules per progetti esterni (anche se sono sconsigliati per la complessità), o tool come monorepo-builder (PHP) o nx (JS).

Consiglio: Non passare a monorepo se non hai problemi reali di dipendenze incrociate. Un repository per progetto è più semplice da gestire per la maggior parte delle PMI. Noi abbiamo scelto monorepo solo quando i progetti hanno iniziato a condividere molto codice e la sincronizzazione manuale diventava un costo.

Azioni immediate: Se valuti un monorepo, prima struttura in sottocartelle (projects/myapp, shared/lib) e usa editor con filtro per cartelle. Poi impara git worktree per avere più branch aperti contemporaneamente.

In sintesi

Git non è uno strumento che si impara una volta e basta. Si evolve con il team e il progetto. Abbiamo visto sviluppatori che lo usano da anni e ancora fanno errori di base. Per questo abbiamo scritto questa guida: non per elencare comandi, ma per trasferire una mentalità — ogni modifica è tracciata, ogni errore è recuperabile, ogni collaborazione è ordinata.

Azioni da fare oggi:

1. Installa Git e configura nome e email (git config --global user.name).
2. Crea un repository locale per un progetto attuale e inizia a committare regolarmente.
3. Aggiungi un hook pre-commit che esegua un linter.
4. Esplora git log --graph --oneline per capire la storia del tuo repository.
5. Se lavori in team, attiva le PR e le branch protection su GitHub.

Il codice che scrivi merita di essere preservato e gestito professionalmente. Git è il primo passo. Il secondo siamo noi, se hai bisogno di supporto su progetti complessi.

Risorse esterne: Documentazione ufficiale Git | Tutorial Atlassian | Wikipedia Git