Perché il versionamento del codice è vitale per la tua azienda: i rischi nascosti del non usare Git

Dopo oltre vent'anni di consulenza su applicativi PHP per Piccole e Medie Imprese, continuo a incontrare aziende che sviluppano software senza alcun sistema di version control. Il codice "versionato" in cartelle rinominate gestionale_v2_finale_DAVVERO_finale, le modifiche in produzione fatte via FTP sovrascrivendo i file, i backup manuali su chiavette USB o su cartelle condivise in rete. Sembra un'esagerazione, ma è la realtà di molte PMI italiane - e le conseguenze, quando qualcosa va storto, sono devastanti.

In un progetto per un'azienda del settore servizi digitali, sono stato chiamato dopo un incidente che aveva bloccato le operazioni per tre giorni: uno sviluppatore aveva sovrascritto via FTP un file critico del gestionale in produzione, eliminando involontariamente una modifica fatta dal collega la settimana precedente. Non esisteva storico delle modifiche, non c'era modo di capire cosa fosse cambiato, e il backup più recente aveva 12 giorni. Dopo il ripristino - parziale, perché 12 giorni di modifiche erano persi - abbiamo implementato Git su tutti i repository dell'azienda e migrato il deploy da FTP a un processo automatizzato. Da quel momento, zero incidenti di questo tipo.

Cos'è il version control e perché è un requisito, non un'opzione?

Un sistema di version control traccia ogni modifica al codice sorgente nel tempo: chi l'ha fatta, quando, cosa è cambiato e perché. Non è un backup - è una cronologia completa e navigabile dell'evoluzione del software. Quando qualcosa si rompe, puoi identificare esattamente quale modifica ha introdotto il problema, chi l'ha fatta e tornare allo stato precedente in secondi. Senza version control, un errore in produzione richiede ore di investigazione manuale e, spesso, non è risolvibile perché lo stato precedente semplicemente non esiste.

Git è lo standard de facto. Creato da Linus Torvalds nel 2005 per lo sviluppo del kernel Linux, è un sistema distribuito: ogni sviluppatore possiede una copia completa del repository con tutta la cronologia. Questo significa che non esiste un singolo punto di fallimento - se il server centrale va giù, ogni copia locale contiene l'intera storia del progetto. Git è gratuito, open source e supportato da piattaforme come GitHub, GitLab e Bitbucket che aggiungono code review, issue tracking e automazione CI/CD.

I benefici operativi per una PMI:

• Tracciabilità completa: ogni commit registra autore, data, messaggio descrittivo e diff esatto. Fondamentale per audit, compliance GDPR e debugging.
• Rollback istantaneo: un deploy ha rotto la produzione? git revert riporta il codice allo stato precedente in un comando.
• Collaborazione senza conflitti: più sviluppatori lavorano in parallelo su branch separati. Git gestisce il merge automaticamente nella maggior parte dei casi, e segnala i conflitti quando servono decisioni umane.
• Branching leggero: creare un branch per una nuova funzionalità costa zero. Se la funzionalità non funziona, si elimina il branch. Il codice stabile non viene mai toccato.

I rischi concreti di lavorare senza version control

Le PMI che sviluppano senza Git si espongono a rischi che non sono teorici - li vedo materializzarsi regolarmente.

La perdita irreversibile di codice è il rischio più grave. Un file sovrascritto, un disco che si guasta, un laptop rubato: senza version control, il codice perso è perso per sempre. I backup periodici (quando esistono) hanno gap temporali che possono significare giorni o settimane di lavoro cancellato.

Il conflitto di modifiche è il rischio quotidiano. Quando due sviluppatori modificano lo stesso file e lo caricano via FTP, l'ultimo sovrascrive il primo. Senza merge, senza notifica, senza possibilità di recupero. Con Git, il merge è un'operazione gestita: i conflitti vengono rilevati, mostrati e risolti esplicitamente.

La mancanza di tracciabilità impatta la sicurezza e la compliance. Chi ha introdotto quella modifica che ha causato il bug in fatturazione? Quando è stata fatta? Era autorizzata? Senza git log e git blame, queste domande non hanno risposta. Per normative come GDPR e NIS2, la tracciabilità delle modifiche al software che tratta dati personali non è un nice-to-have ��� è un requisito. Ho trattato i rischi di sicurezza legati ai repository Git in un articolo sulle minacce nascoste nei repository.

L'impossibilità di automatizzare i deploy è la conseguenza operativa diretta. Senza Git, il deploy è manuale: copia file via FTP, spera di non aver dimenticato nulla. Con Git, il deploy diventa un git pull (o meglio, un processo automatizzato con Deployer) che garantisce atomicità, rollback e zero dimenticanze.

Il workflow Git essenziale per una PMI

Non serve padroneggiare ogni funzionalità di Git per ottenere benefici immediati. Un workflow base che copre il 90% delle esigenze di una PMI:

git init                       # inizializzare il progetto
git add .
git commit -m "feat: importazione iniziale del progetto"
git remote add origin [email protected]:azienda/gestionale.git
git push -u origin main

git checkout -b feature/nuovo-report-vendite
                               # branch dedicato alla nuova funzionalità
git add src/Reports/VenditeReport.php
git commit -m "feat: aggiunto report vendite mensile con export PDF"
git push origin feature/nuovo-report-vendite
                               # → Pull Request su GitHub/GitLab
                               # → code review → merge in main

git log --oneline -10          # ultimi 10 commit
git revert abc1234             # annulla un commit specifico
git push origin main           # deploy del fix

L'elemento chiave è che ogni modifica passa attraverso un branch dedicato e una pull request. Questo significa che il codice viene rivisto da un collega prima di entrare nel branch principale - un processo che intercetta bug, vulnerabilità e errori logici prima che raggiungano la produzione.

Strategie di branching: quale scegliere per il tuo team

La scelta della strategia di branching dipende dalla dimensione del team e dalla frequenza di rilascio.

Per le PMI con team di 1-5 sviluppatori e rilasci frequenti, il GitHub Flow è la scelta pragmatica: un branch main sempre deployabile, feature branch di breve durata (24-48 ore), pull request con code review, merge e deploy. È semplice, lineare e si integra naturalmente con la CI/CD.

Per team più grandi o con cicli di rilascio pianificati (release mensili, versioni multiple in produzione), Git Flow aggiunge branch develop, release/* e hotfix/* che separano il codice in sviluppo dal codice stabile. La complessità aggiuntiva è giustificata solo quando servono effettivamente release parallele - per la maggior parte delle PMI, GitHub Flow è sufficiente.

Indipendentemente dalla strategia, alcune regole sono universali: il branch main deve essere protetto (nessun push diretto, solo merge via pull request), ogni commit deve avere un messaggio descrittivo che spieghi il perché della modifica (non il cosa, che è già nel diff), e le pull request devono richiedere almeno una approvazione prima del merge.

Il .gitignore: cosa non deve mai finire nel repository

Un errore che vedo con frequenza preoccupante nelle PMI che adottano Git per la prima volta è committare nel repository file che non dovrebbero esserci: credenziali, file di configurazione locale, dipendenze, file generati. Il file .gitignore definisce cosa Git deve escludere:

/vendor/
/node_modules/
.env
.env.backup
storage/*.key
storage/logs/
storage/framework/cache/
storage/framework/sessions/
storage/framework/views/
*.sqlite
*.sqlite-journal
npm-debug.log
yarn-error.log
.phpunit.result.cache
.idea/
.vscode/
*.swp

Due regole fondamentali: il file .env con le credenziali non deve mai essere committato (nel repository va solo .env.example con i placeholder), e la directory vendor/ (le dipendenze Composer) non va versionata - si ricostruisce con composer install. Se credenziali sono state committate in passato, non basta rimuoverle dall'ultimo commit: restano nella cronologia Git e devono essere considerate compromesse. La gestione sicura della configurazione e dei secret è un aspetto che merita un approfondimento specifico.

Dalla cartella "backup_finale" a un flusso professionale

Adottare Git non è un progetto complesso: per un singolo applicativo, la migrazione da "cartelle rinominate" a un repository Git con branching e code review si completa in una giornata. Il valore che genera - tracciabilità completa, collaborazione sicura, deploy automatizzabili, rollback istantanei - è sproporzionato rispetto all'investimento iniziale. Ogni giorno senza version control è un giorno in cui il codice della tua azienda è esposto a perdite che nessun backup potrà recuperare completamente. Se il tuo team sviluppa software senza Git e vuoi strutturare un workflow professionale, la mia esperienza ventennale nella migrazione di progetti legacy al version control è a tua disposizione. Contattami per una consulenza e partiamo dal tuo caso specifico.