Articoli informativiPrincipiantiTips

Usare Git in Unity

Cos'è Git?

Diamo per scontato che non sappiate nulla su Git e che siate alle prime armi con lo sviluppo di software in generale.

Git è uno strumento che vi permetterà di avere una copia del vostro progetto costantemente aggiornato, situato su un server. Anche se il vostro PC dovesse smettere di funzionare, il vostro progetto sarà sempre sempre al sicuro.
E' uno strumento essenziale ed estremamente consigliato nella maggior parte dei casi, sopratutto in progetti medio/grandi ed indispensabile per poter avere una copia del progetto condivisa tra diversi membri di un team.

Git è  un "sistema di controllo di versione "che terrà traccia di tutte le modifiche che farete sui files del progetto e che potrete sempre "rettificare" senza il rischio di perdere il lavoro in caso di problemi e senza dover fare delle pesanti copie di backup prima di ogni modifica che riteniamo "pericolosa".
Possiamo asserire che tramite l'uso di un servizio Git sarà quasi impossibile non trovare rimedio ad un eventuale errore di valutazione o bug che impedisce il corretto funzionamento del progetto. Con Git sarà sempre possibile "tornare indietro" o rettificare solo determinate modifiche a specifici files del progetto che abbiamo deciso di "scartare".
Ovviamente questo non è il solo beneficio di uno strumenro come Git. Ma noi ne vedremo solo alcuni basilari come l'invio di modiche e il ritorno ad una versione precedente alle modifiche.

Con Git avremo una copia del nostro progetto al sicuro sulla rete, costantemente aggiornata e condivisibile.

Questo articolo si rivolge ovviamente all'uso di Git su un progetto in Unity, ma la procedura sarebbe quasi identica per qualsiasi tipo di progetto.

Perché usare Git invece di fare delle copie del progetto?

1. Prima di tutto perché non potete sempre sapere quando si potrebbe presentare un eventuale problema a cui porre rimedio e potreste non essere in grado di tornare indietro nell'esatto momento prima del problema se non cancellando anche altre modiche e dover quindi rifare una parte del lavoro già svolto. Sempre che vada tutto bene dovreste fare una copia dell'intero progetto (che potrebbe occupare anche decine di GB) ad ogni fine sessione di lavoro.

2. In secondo luogo, creare una copia di un progetto ad ogni modifica, potrebbe tenere impegnato il computer per ore, sopratutto quando un progetto è abbastanza consistente. Git invece invierà alla "copia di backup" solo le effettive modifiche effettuate evitando di "toccare" (inviare o scaricare) i files che non sono stati modificati, risparmiando tempo e spazio. Se per esempio su un pregetto di 10Gb farete delle modiche a degli scripts (dunque modifiche di pochi Kb), non dovrete fare la copia di tutti i 10Gb del progetto, pur non sapendo quali files sono stati modificati nello specifico. L'invio delle modifiche comprenderà solo i pochi Kb modificati. Dunque lavorare su un progetto condiviso non porterà problemi di download/upload, anche in presenza di un progetto molto grande, perché quando si dovrà aggiornare il progetto si riceveranno/invieranno automaticamente solo le modifiche effettuate dall'ultimo aggiornamento.

3. Una delle utilità di Git è inoltre la possibilità della condivisione del progetto su cui più persone possono lavorare contemporaneamente, avendo una copia comune su server a cui inviare le modifiche, creando rami con versioni differenti che potrete integrare al ramo principale una volta approvate.

4. Avrete sempre la possibilità di tornare a qualunque versione precedente del progetto, con pochi click, anche a versioni create molto tempo prima.

5. Avrete sempre una traccia minuziosa di qualsiasi piccola modifica effettuata, sia a livello di files (immagini, suoni, modelli, ecc..) che a livello di testo/codice, in modo automatico e sempre chiaro.

6. Ultimo ma non meno importante, la comodità di avere un back-up aggiornabile con paio di click, senza lunghe attese e senza doversi preoccupare dell'integrità del proprio computer o dell'uso di scomode e poco affidabili chiavette USB.

L'approccio di creare costantemente copie del progetto è stato usato in molti grandi progetti software. Sebbene questo metodo possa funzionare, è altamente inefficiente (dato che verranno conservate molte copie quasi identiche del software), richiede molta disciplina da parte degli sviluppatori e conduce spesso ad errori. (fonte: Wikipedia)

 


 

Premessa

Nel nostro caso cercheremo di usare Git nella maniera pù semplice possbile.
Useremo un serivizio (gratuito) chiamato GitHub che vi permetterà di "salvare" il vostro progetto su un server on-line e insieme ad un piccolo programma per desktop chiamto GitHub Desktop che vi permetterà di inviare/ricevere le modifiche e tenere traccia di tutti i vari cambiamenti che farete su di esso nel tempo.
E' possibile anche utilizzare propri servers o addirittura avere dei "depositi" in locale sullo stesso computer su cui lavorate. I servizi più blasonati sono GitHub, GitLab e Bitbucket , tutti provvisti di pacchetti gratuiti che necessitano di una semplice registrazione.

Quando Git è installato sul sistema, è possibile effettuare tutte le operazioni da riga di comando, ma sono disponibili numerosi client grafici gratuiti. Noi utilizzaremo appunto GitHub Desktop con cui è possibile interagire tramte una semplice finestra che ci permetterà l'invio e la ricezione delle modifiche al progetto che sarà presente in rete.

Terminologie

Fin'ora abbiamo usato parole come backup, salvataggio, cloud... ma esistono delle terminologie ben precise con cui dovrete prendere confidenza. Nulla di troppo compicato. Le più importanti da coprendere sono le prime tre o quattro della lista qui sotto e tenete comunque presente che si tratta di concetti di cui conosciamo già il  significato, solo chiamati in modo differente.
Per esempio, i servizi come Git vengono chiamati comunemente "controllo versione" (version control system).
Vediamo alcuni termini essenziali:

- REPOSITORY:  Il "posto" in cui si trova la copia di backup viene chiamata Repository (deposito) spesso abbreviato in repo.
- COMMIT:  Per effettuare l'invio di modifiche alla Repository è necessario fare prima un Commit ovvero una "commissione". Un Commit crea degli speciali files sul proprio PC che contengono le modifiche effettuate. Ma finchè non le invierete sulla Repository essere rimarranno sul computer in cui sono state fatte.
- PUSH: Una volta creato un Commit si potrà procedere all'invio delle modifiche sulla Repository con il comando chiamato Push/Fetch.
- PULL:
significa appunto, "tirare" ovvero "andare a prendere" le eventuali modifiche della repository che non avete ancora sul vostra copia locale (nel caso in cui lavoriate in un team, andrete a prendere i commits effettuati dagli altri, aggiornando così la vostra copia del progetto).
- FETCH: con il comando fetch aggiornerete il progetto, sia che dobbiate prendere modifiche che inviarle.

Questi primi termini possono essere sufficienti per lavorare tranquillamente con Git, almeno agli inizi.
Potrà però capitare di imbattervi in altri termini di cui ignorate l'esatta azione a cui si rifriscono.
Per non rimanere troppo spiazzati e confusi, ve ne elenco alcuni.

- CLONING: Come suggerisce il nome, clonare un progetto vuol dire in sintesi copiare tutto il repository sul nostro coputer.
- BRANCH: Come accennato in precedenza, Git ci permette dicreari rami indipendenti che poi si potranno fondere con il ramo principale.
- MASTER: Nel momento della creazione della repository verrà creato il ramo di base, chiamato appunto, Master.
- FORKING: Nel caso in cui si lavori in un team ci saranno diversi contributor ovvero diverse persone che lavorano allo stesso progetto. Creando una bifocazione si creerà una nuova copia della repository su cui ogni contributor potrà lavorare indipendentemente. Ogni contributor avrà dunque una sua personale repository a cui inviare modifiche.


Iniziamo

Come primo passo dovremmo registrarci su un servizio Git.
In questo caso useremo GitHub, che è sicuramente il servizio Git più diffuso.
Le differenze tra i vari servizi Git sta nei costi delle versioni più avanzate, le dimensioni massime di una repository, la possibilità di avere repository private o pubbliche ecc...
Se siete interessati potrete trovare una lista dei migliori servizi in circolazione a questo indirizzo: https://financesonline.com/version-control-systems

 

Registrazione su GitHub

Andimao sul sito https://github.com e procediamo alla registrazione.
Potremmo semplicemente fermarci qui e GitHub funzionerebbe perfettamente. È comunque una buona idea installare Git sul proprio computer, se non già fatto.  Adiamo sul sito https://gitforwindows.org scarichiamo la versione più recente e installiamola.
A questo punto siamo perrfettamente in grado di usare il servizio, per farlo useremo GitHub Desktop.

Andiamo a scaricare GitHub Desktop, il programma con cui interagire con la nostra repository, senza l'uso di complicati comandi da imparare. Come da preposta, siamo agli inizi e preferiamo usare un programma visuale per interagire con la nostra repository, anche se in realtà sarebbe possibile farlo da comandi testuali con cui sarebbe possibile effettuare molte più operazioni.

Scarichiamo l'ulima aversione di GitHub Desktop da questo sito: https://desktop.github.com
Tenete presente che tramite questo programma potremmo interagire allo stesso identico modo anche se la nostra repository si trovasse su un servizio Git differente da GitHub, come per esempio l'altrettando validissimo GitLab.

 

 
Usiamo GitHub Desktop

Apriamo il programma GitHub Desktop.
A questo punto, ipotizziamo che abbiate già un progetto iniziato e lo volete inserire su GitHub da zero.
Facciamo click su File->New Repository.
E' importante che il nome della Repository si chiami esattamente come il nome della cartella principale del progetto, nel caso di questo esempio, TestUnityProject.

Fate attenzione:
su location path non dovrete inserire il path completo del progetto, ma solo il percorso di dove si trova la cartella del progetto. Nel mio caso il progetto si trova in D: e non dovrò inserire altro.

Come da foto precedente, nul menu a discesa Git Ignore scegliamo Unity.

Cos'è Git Ignore?

Git Ignore è un file di testo che verrà generato automaticamente all'interno della cartella del vostro progetto. All'interno di questo file saranno elencati i files da ignorare quando verrà effettuato un qualunque aggiornamento della repository. Nel caso di Unity verranno ignorate alcune cartelle, come la cartella Buld, la cartella Library e diverse altre, oltre che ad alcuni tipi di files che non sarà necessario inviare alla repository. E' buona norma tenere sulla repository solo la cartella Assets e poco altro. In coso si grossi progetti si dovrebbero tenere sulla repository solo i files che riguardano il codice e lasciare i files più pesanti (come le textures ecc...). Ma per ora teniamo per buono il Git Ignore di default di Unity.

Premiamo sul pulsante blu "Create Repository".
A questo punto la nostra Repository è stata creata! 😆 Ma è ancora presente solo sul nostro computer. 🙄 
Diamo un'occhiata al layout del programma.

Un'occhiata a come è cambiata la cartella del progetto

Se provate ad aprire la cartella del vostro progetto ora troverete all'interno di essa una nuova cartella chiamta .git.
E' all'interno di essa che verranno creati i files delle repository. A voi questo non deve importare, sappiate solo che è normale che sia lì. Potrebbe capitare che non vediate la cartella a causa del fatto che essa è nascosta. E' dunque molto consigliato non modificare i files al suo interno.
Come vedete anche il file .gitIgnore è lì e volendo sarà modificabile con qualsiasi editor di testo.

Torniamo al programma GitHub Desktop.
Premiamo sul pulsante Publish Repository in alto (o sul pulsante blu Publish Repository).
Ci sarà d'attendere un po' a seconda delle dimensioni del vostro progetto. Durante quest'attesa il programmas sta facendo l'upload del Commit del progetto (in questo caso il Commit iniziale, ovvero la prima pubblicazione).

Se ora provate ad andare di nuovo sul sito https://github.com troverete il vostro progetto nella lista delle vostre Repository. State usando a tutti gli effetti Git, il vostro progetto è al sicuro!

Sul pannello History vedrete ora che c'è il primo Commit, chiamato Initial Commit.
Da ora in poi i Commit inviati saranno elencati su questa schermata.

Riassumendo

- Appena farete delle modifiche a qualsiasi file del vostro progetto, essa verrà evidenziata nel pannello Changes.
- A quel punto potrete creare un Commit che conterrà le modifiche effettuate.
- Ricordate che nel momento della sua creazione è necessario inserire un nome per il Commit e se volte, ma non necessariamente, anche una descrizione.
- Una volta creato, il Commit esso sarà pronto per essere "spedito" alla Repository, come avete fatto la prima volta, con il comando Fetch o Push.

- Nel caso in cui vogliate fare un Revert, vi basetrà andare nel pannello History e cliccare con il tasto destro su un Commit e scegliere "Revert this commit".
Le modifiche saranno apportate istantaneamente anche alla vostra copia in locale.

NOTA:
Sappiate che ogni volta che farete delle modifiche alla scena del vostro gioco su Unity dovrete salvare la scena (CTRL+S) prima di creare un Commit che contenga anche quelle modifiche. Lo stesso dicasi per gli scripts.
In pratica le modifiche vengono intercettate solo sui files salvati.

 

Correre ai ripari

CASO 1
Poniamo il caso in cui abbiate lavorato sul vostro progetto e avete salvato il progetto/scena... Magari più volte.
Ma poi vi accorgete che qualcosa non funziona più e non riuscite a risalire al problema che potrebbe essere incorso molti salvataggi prima, senza esservene accorti. Anche se non avete fatto un Commit prima delle modifiche, non disperate.

Nel pannello Changes potete rimuovere le modifiche fatte in modo specifico su ogni tipo di file che è stato modificato dall'ultimo commit.
Con Discard Changes il file tornerà alla versione precedente all'ultimo Commit.
Con Discard All Changes tutti i files elencati nel pannello Changes torneranno alla versione precedente all'ultimo Commit.

ATTENZIONE a questi comandi, essi sono inreversibili. In pratica sarà come se le ultime modifiche (elencate e dettagliate nel pannello Changes) non siano mai state fatte!

 

CASO 2
Poniamo un secondo caso, quello in cui abbiate già creato un Commit e nel pannello Changes non appaiono più le modifiche sui singoli files.
Vi accorgete però che c'è qualcosa che non va e non volte spedire il Commit sulla Repository.

Siete nella situazione come in questa immagine e volete tornare indietro per modificare qualche file prima di fare il Commit.
Come evidenziato, esiste un piccolo pulsante "undo" con cui potete tornare indietro, elminando il Commit.
State tranquilli, questo comando non annullerà le modifiche fatte ai files ma semplicemente eliminerà la registrazione del Commit, facendovi tornare a vedere le modifiche fatte ad ogni singolo file.

 

Non resta altro che ricordarvi di fare un Commit+Fetch ogni volta che chiudete il vostro progetto, a fine giornata o ogni qual volta vogliate.

Limitazioni

Ci sarebbero un bel po' di cose di cui parlare a riguardo di git e delle opzioni offerte dai vari serivzi.
Potrete trovare maggiori informazioni leggendo le specifiche opzioni di ogni servizio, per ora sappiate solo che sia GitHub che GitLab rappresentano entrambe ottime soluzioni.

Fino a poco tempo fa GitHub non offriva la possibilità di avere Repository private se non a pagamento. Avere una Repository pubblica vuol dire che sarà visionabile e scaricabile da chiunque.
Fortunatamente adesso non è più così ed è possibile marcare la propria Repository come privata, anche ulizzando il pacchetto free, cosa che è sempre stata possibile su GitLab.

Al momento GitLab offre un servizio leggeremete migliore grazie ai suoi 10Gb massimi per Repository. Mentre GitHub offre solo 1Gb. In realtà le dimensioni di 1Gb di GitHub sono "consigliate", ovvero, il team di GithHub consglia all'utente di informare i gestori del servizio nel caso la propria Repository superi 1Gb ed è molto probabile che continuerà a funzionare tutto come prima.
Mentre se seuperate i 10Gb di GitLab il servizio non vi permetterà più di fare nulla, neanche per ridurre le dimensioni della Repository. Dunque avrete grossi problemi nel tornare indietro e l'unica soluzione potrebbe essere solo quella di creare una nuova Repository.

100Mb per file!
Un limite importante da tenere presente sono le dimensioni di un unico file, ovvero 100Mb. Non è possibile inviare un file dalle dimensioni maggiori, sia che usiate GitHub o altro servizio. Fate dunque attenzione se usate textures di grandi dimensioni, sopratutto se in formato .psd che spesso, in presenza di molty Layers, potrebbero sforare questo limite.


In questo articolo abbiamo appena scalfito la superficie delle potenzialità  di un sistema di controllo versione, ma ora avete almeno le basi per poter fare i vostri test con GitHub e dormire sonni più tranqilli. 😉 

Un pensiero su “Usare Git in Unity

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *