Git

Un sistema che tiene traccia delle modifiche a un insieme di file. Registra ogni versione con data, autore e motivo del cambiamento, e consente di tornare indietro, di confrontare due momenti e di capire chi ha cambiato cosa e perché.

Il problema che risolve

Due: la storia e il lavoro in più persone. Senza, la storia del progetto sta nei nomi dei file e nella memoria di chi c'era; e quando due persone toccano lo stesso script, una delle due versioni muore. Con Git le modifiche si uniscono, e dove si scontrano il conflitto viene mostrato invece che nascosto.

Perché riguarda la statistica più di altri mestieri

Perché i risultati devono essere difendibili. Quando a distanza di mesi un revisore o un committente chiede come è stato prodotto quel numero, la risposta è la versione esatta del codice che lo ha generato. È la stessa logica della tracciabilità del dato, applicata all'analisi.

Git e GitHub non sono la stessa cosa

Git è lo strumento e funziona sul vostro computer, anche senza rete e senza che nulla esca dall'azienda. GitHub e simili sono servizi che ospitano una copia condivisa del progetto. Si può usare il primo senza i secondi, e quando i dati sono riservati è spesso l'unica configurazione ammessa. Il nostro repository RHO Lab sta lì.

Un esempio: il file che decide cosa resta fuori

Ogni progetto dovrebbe nascere con un file .gitignore, che elenca ciò che Git non deve mai registrare. Per un progetto di analisi con dati riservati, un punto di partenza ragionevole è questo:

# data never goes into the repository
data/
*.csv
*.xlsx
*.parquet

# credentials and local settings
.Renviron
.env

# generated files
output/
.Rhistory
.RData

I dati restano nella loro cartella, sul disco o sul server, e il repository contiene solo il codice che li legge. Le credenziali stanno in un file locale che non viaggia. Chi riceve il progetto ottiene tutto ciò che serve per rifare l'analisi, tranne ciò che non deve avere.

Il punto delicato: cosa non va messo dentro

Mai dati, mai credenziali. Git conserva la storia, quindi un file di dati committato per errore resta nella cronologia anche dopo averlo cancellato, e toglierlo davvero è un lavoro. Si previene dichiarando fin dall'inizio quali cartelle vengono ignorate, come nell'esempio.

Gli errori che si fanno tutti

• Il .gitignore scritto dopo. Un file aggiunto prima di essere ignorato continua a essere seguito. Va tolto esplicitamente con git rm --cached, e la sua storia resta comunque.
• I fine riga di Windows. Windows e gli altri sistemi chiudono le righe in modo diverso, e uno script può risultare modificato in ogni riga senza che nessuno l'abbia toccato. Su Windows si imposta una volta git config --global core.autocrlf true.
• I messaggi che non dicono niente. Una storia fatta di "modifiche" e "fix" non risponde alla domanda di sei mesi dopo. Il messaggio deve dire perché, non cosa: il cosa lo mostra già Git.
• Una sola registrazione alla fine della giornata. Modifiche piccole e separate si capiscono e si annullano una per una; un blocco unico no.

Dove si prende

Git è gratuito e open source, si scarica da git-scm.com; su Windows la distribuzione è Git for Windows, che include anche un terminale. RStudio e Visual Studio Code hanno un pannello integrato che copre le operazioni quotidiane senza scrivere comandi.

Per imparare

Il libro Pro Git, gratuito sul sito ufficiale, con una traduzione italiana parziale, è il riferimento completo. Per chi lavora con R, Happy Git and GitHub for the useR di Jenny Bryan parte dall'installazione e arriva ai flussi di lavoro quotidiani.

Quando ha senso adottarlo

Dal secondo progetto in poi, e immediatamente se siete più di uno a toccare lo stesso codice. È lo strumento con la curva di apprendimento più ripida dell'elenco e quello che, una volta preso, cambia di più il modo di lavorare.