Controllo versioni nella condivisione file: evita il caos delle sovrascritture

Il GDPR, all'articolo 5, paragrafo 1, lettera f), impone che i dati personali siano trattati in modo da garantirne un'adeguata sicurezza, compresa la protezione contro perdite o distruzioni accidentali. Una sovrascrittura su un file condiviso — un evento che accade ogni giorno in ogni team — può costituire esattamente questa violazione. Eppure la maggior parte delle organizzazioni non ha ancora un sistema serio di controllo versioni per i file non-codice.

Il modo per eliminare il caos da sovrascrittura usa tre strumenti che lavorano insieme: la cronologia versioni nativa sulla piattaforma di sincronizzazione (Google Drive mantiene 100 versioni o 30 giorni, Dropbox Business 180 giorni, OneDrive 500 versioni), il blocco check-in/check-out per i file che solo una persona dovrebbe modificare alla volta (SharePoint, Box, o DAM come Bynder), e Git o Git-LFS per tutto ciò che è basato su testo o dove serve la ramificazione esplicita. Aggiungete in cima una convenzione di denominazione con suffissi vNN e ottenete sia il ripristino automatico sia le istantanee intenzionali.

Le tre modalità di fallimento dei file condivisi

Ogni disastro da sovrascrittura rientra in uno di tre schemi. Riconosceteli e le soluzioni diventano ovvie.

Collisione da salvataggio simultaneo: due persone modificano lo stesso file contemporaneamente; l'ultimo salvataggio vince, il lavoro del primo salvataggio scompare. Soluzione: co-authoring in tempo reale (Google Docs, Office Online) o blocco esplicito (checkout SharePoint).
Sovrascrittura per errore: qualcuno apre "il file", lo modifica, salva sopra la copia canonica pensando di salvare una copia di lavoro personale. Soluzione: separazione netta tra sorgente di verità e copie di lavoro, con la canonica in sola lettura.
Storia perduta: un file era corretto tre versioni fa ma lo stato attuale è rotto e nessuno riesce a ricostruire i passaggi intermedi. Soluzione: cronologia versioni mantenuta sulla piattaforma più istantanee disciplinate.

La maggior parte dei team sperimenta tutti e tre. La soluzione composita usa strumenti diversi per modalità di fallimento diverse.

Co-authoring in tempo reale per i documenti vivi

Per testi e fogli di calcolo che molte persone modificano, il co-authoring in tempo reale elimina completamente le collisioni da sovrascrittura. Google Docs, Sheets e Slides gestiscono oltre 100 editor simultanei senza problemi. Microsoft 365 Word Online ed Excel Online sono vicini in termini di parità, con maggiore fedeltà ai formati .docx legacy.

Notion, Coda e Airtable estendono questo a documenti strutturati e database con operational transform o merge basato su CRDT. Figma fa lo stesso per i file di design con un motore multiplayer personalizzato.

Quando scegliete uno strumento, verificate che il co-authoring in tempo reale funzioni sulle dimensioni reali dei vostri file. Alcuni strumenti degradano oltre 1.000 righe o 50 pagine. Testate con dati realistici prima di impegnare tutto il team.

Blocco check-in/check-out per i file binari

I file binari — PSD, .ai Illustrator, .indd InDesign, .rvt Revit, .prproj Premiere, .dwg AutoCAD — non possono unire i conflitti in modo pulito. Due persone che modificano significa che i cambiamenti di una moriranno. Il blocco esplicito è la risposta.

Strumenti con check-in/check-out maturo:

SharePoint: check-in/check-out nativo su qualsiasi libreria. Sottoutilizzato ma solidissimo.
Box: blocco file con indicatore di "chi ce l'ha"
Bynder, Frontify, Brandfolder: DAM con blocco integrato per gli asset creativi
Perforce Helix Core: lo standard del settore per studi di gioco e case VFX — commit atomici su centinaia di gigabyte di asset binari

Per i team che usano Dropbox o Drive senza blocco nativo, il blocco disciplinare funziona: un file BLOCCATO-proprietario.txt nella cartella, o un messaggio fissato su Slack nel canale del progetto. Fragile ma accettabile per team piccoli.

Git e Git-LFS per tutto ciò che è basato su testo

Git è lo standard del controllo versioni. Usatelo per:

Codice sorgente (ovviamente)
Documenti in Markdown, wiki e basi di conoscenza interne
File di configurazione (YAML Kubernetes, Terraform, Ansible)
Schema di dati (Prisma, modelli dbt, migrazioni SQL)
Tutto ciò su cui volete ramificazione esplicita, diff e code review

Git-LFS estende Git agli asset binari di grandi dimensioni. Memorizza i blob binari su un server separato e Git tiene traccia dei puntatori. Git-LFS di GitHub è gratuito fino a 1 GB di storage e 1 GB di banda mensile; i data pack da 5 dollari al mese aggiungono 50 GB ciascuno.

Per i team che abbinano Git al lavoro creativo — siti marketing con immagini integrate, progetti di gioco con PSD accanto al codice — Git-LFS li unisce. Per il lavoro puramente creativo senza codice adiacente, i DAM o Perforce si adattano meglio.

Cronologia versioni nativa: la rete di sicurezza

Ogni strumento di sincronizzazione principale mantiene automaticamente la cronologia versioni. Conoscete i vostri default:

Google Drive: 100 versioni o 30 giorni, il più tardi dei due. I piani Workspace estendono a 100 versioni senza limite di tempo per i formati non-Google.
OneDrive e SharePoint: 500 versioni per impostazione predefinita, configurabile per libreria
Dropbox: 30 giorni su Basic, 180 giorni su Business, 365 giorni su Advanced, illimitato su Enterprise
Box: 100 versioni su Business, illimitato su Enterprise
Apple iCloud Drive: solo 30 giorni; il più debole tra i principali

Verificate che il vostro piano abiliti effettivamente ciò che pensate. Alcune organizzazioni scoprono durante una crisi che l'amministratore aveva ridotto la conservazione per risparmiare spazio di archiviazione due anni prima.

Convenzioni di denominazione come istantanee esplicite

La cronologia versioni automatica è ottima per piccoli ripristini. Per i traguardi di progetto, le istantanee denominate esplicitamente sono più chiare. La convenzione vNN nei nomi file fornisce istantanee in un momento preciso che gli esseri umani possono navigare:

2026-06-12_ACME-RB_spec_v01.pdf
2026-06-15_ACME-RB_spec_v02.pdf
2026-06-19_ACME-RB_spec_v03.pdf

Quando qualcuno chiede "cosa abbiamo inviato al cliente il 15 giugno?", potete rispondere senza cercare nei metadati della cronologia versioni. Denominate le versioni principali e lasciate che la cronologia automatica gestisca gli intermedi.

Esercitazioni di ripristino che provano che il sistema funziona

Un backup che non testate mai non è un backup. Lo stesso vale per la cronologia versioni. Una volta al trimestre, scegliete un file casuale, dichiarate che era stato corrotto ieri, e cronometrate quanto ci vuole per ripristinare la versione precedente. Se ci vogliono più di 10 minuti, qualcosa non va — forse la conservazione dello strumento di sincronizzazione è più breve di quanto pensiate, forse nessuno sa dove si trova l'interfaccia della cronologia.

Documentate la procedura di ripristino per ciascuno dei vostri strumenti. Gli screenshot aiutano. Fissate il documento alla radice del drive condiviso.

Ramificazione per il lavoro sperimentale

A volte uno spike "e se provassi questo" non dovrebbe toccare il file canonico. Per il codice sorgente, ramificate in Git (git checkout -b esperimento/nuovo-hero). Per i file creativi, l'equivalente è una cartella parallela:

/Progetti/ACME-RB/02-lavoro/
/Progetti/ACME-RB/02-lavoro/esperimento-direzione-alternativa/

Lavorate nella cartella dell'esperimento finché non sostituisce la direzione principale (spostatelo in 02-lavoro/, rinominate il canonico) o viene accantonato (rimane nella cartella dell'esperimento come registro dell'esplorazione).

Questo schema impedisce al lavoro "e se" di inquinare i file di lavoro principali pur preservandolo come riferimento valido.

Risoluzione dei conflitti quando accade comunque

Anche con tutto quanto sopra, i conflitti accadono. Gli strumenti di sincronizzazione li gestiscono in modo diverso:

Google Drive: l'ultimo salvataggio vince per i formati non-Google. Usate Docs/Sheets/Slides per i file che co-modificherete.
Dropbox: crea un file "Copia in conflitto" con il nome dell'editor. Revisionate e unite manualmente, o eliminate se ridondante.
OneDrive: similmente — Documento_utente1.docx rispetto al canonico.
Git: marcatori di conflitto di merge espliciti che richiedono risoluzione umana. Inequivocabile ma ostile.

Insegnate al vostro team a guardare effettivamente i file di copia in conflitto invece di ignorarli. Una copia in conflitto di tre settimane fa può contenere una modifica critica che nessuno ha notato.

Consegnare file versionati esternamente

Quando una versione deve andare a un cliente — una versione principale specifica che sta revisionando, non il vostro lavoro in corso — inviatela tramite un canale di trasferimento, non un link di sincronizzazione. La condivisione tramite link dal vostro strumento di sincronizzazione rischia di mostrare al cliente una versione in editing che cambia sotto di lui.

Un link di trasferimento cattura il file in un momento e lo spedisce. Servizi come HexaTransfer, Dropbox Transfer e Smash congelano lo stato al momento dell'invio. Il cliente vede esattamente ciò che avete inviato, per sempre, fino alla scadenza del link.

Provate HexaTransfer su https://hexatransfer.com — gratuito, senza account, massimo 10 GB.