Tutti i bravi sviluppatori utilizzano nel loro quotidiano processo di gestione un software di versionamento del codice.
Il sistema di versioning del codice che ormai va per la maggiore è git. Uno strumento di semplice utilizzo che promette ottimizzazioni importanti in termini di archiviazione delle modifiche sul repository server ed una moltitudine di servizi on-line, gratuiti e a pagamento che permettono di tenere al sicuro il proprio codice.
Ma come tutti gli strumenti anche git, se non opportunamente configurato, può portare numerosi grattacapi.
Team con OS differenti
Uno dei primi problemi che si affronta con Git lavorando in team è la diversità degli ambienti di lavoro.
Chi lavora in ambiente Windows, e non ha cambiato le impostazioni del proprio editor di sviluppo, utilizza come separatore di riga la sequenza ASCII CRLF (CR + LF).
Chi lavora invece in ambiente Mac, ed anche in questo caso senza cambiare le impostazioni del proprio IDE preferito, utilizza come separatore di riga il carattere ASCII (CR)
Su Linux invece lo sviluppatore si troverà con un carattere ASCII di terminazione (LF).
Questo si tramuta in un delirio quando si fa un’archiviazione da un utente ed il recupero del codice aggiornato dall’altro, perché i file potrebbero risultare continuamente modificati, mentre facendo un confronto tra le versioni i file risulterebbero apparentemente identici.
Per fortuna una semplice configurazione di Git permette di risolvere il problema:
$ git config --global core.autocrlf trueAttenzione però perchè questo potrebbe danneggiare alcuni file che prevedono in modo stringente che ci sia la sequenza CR+LF. Mi riferisco ai file descrittori delle Solution .NET (estensione .sln).
In questo caso suggerisco di guardare più approfonditamente la documentazione in inglese molto ben dettagliata su GitHub.
Permessi sui file
Altro momento di delirio è la gestione dei permessi sui file.
Può succedere che in ambiente di sviluppo si faccia dei cambiamenti ai permessi sulle directory che però non devono propagarsi sul repository. In questo caso, se si cambiassero i permessi su una cartella soggetta a versionamento, che contiene qualche migliaio di file, Git potrebbe notificare la variazione di altrettanti file, notificando migliaia di falsi positivi.
Per evitare che ciò accada, assumendo che i permessi dei file non siano un problema o un’informazione “importante” nel repository in questione sarà utile il comando:
$ git config --global core.fileMode falseIndica a Git se il bit executable dei file nel working tree è importante.
Alcuni filesystem perdono il bit executable quando un file indicato come eseguibile è recuperato, oppure quando lo trasmettono verso il repository.
Tuttavia, per quanto sembri interessante questo comando, sembra non avere effetto su VSCode… Almeno non in quel formato… Almeno non su Windows.
Per consentire anche all’estensioen Git di VSCode di rendere i file immutati bisogna mettersi nella directory del progetto e specificare la medesima configurazione a livello di progetto.
$ git config core.fileMode falseProblema risolto!
Conclusioni
Sicuramente questo articolo non ha la presunzione di risolvere tutti i problemi di Git ma giusto due, e quelli più “antipatici” in un contesto di OS variegati. Per maggiori approfondimenti suggerisco la lettura della documentazione ufficiale o, per casi specifici, può bastare una buona ricerca su internet in virtù del problema riscontrato.