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 usato anche dai professionisti del settore che vi permetterà di avere una copia del vostro progetto costantemente aggiornato, situato su un server di cui potrete anche ignorare l’ubicazione. 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.

 
Unity Collaborate Vs. Git

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, persino se riguardasse solo assets grafici.
Esiste un servizio molto simile direttamente integrato in Unity che si chiama Unity Collaborate.
Tale strumento è però estremamente limitato. Se pur più facile da usare, Unity Collaborate non permette di eseguire molte operazioni se non le più basilari e manca completamente del sistema di “rami” (che vedremo dopo), essenziale per poter collaborare senza problemi tra diversi membri di un Team. Va detto che Unity Collaborate è uno strumento relativamente giovane e non è detto che un giorno possa essere aggiornato e migliorato nelle sue potenzialità.

Come descritto chiaramente dal Team di Unity parlando del confronto GIT-Collaborate:
“L’idea è quella di fornire un servizio di base simile a qualcosa come GIT ma senza la curva di apprendimento coinvolta. Sebbene GIT sia eccezionale, esso ha una curva di apprendimento e un focus orientato allo sviluppatore che a volte è difficile da far imparare un artista grafico o un programmatore poco esperto. Alcune persone vogliono solo lavorare sulle proprie cose e sincronizzarle con il proprio team. Questo è ciò che stiamo cercando di fornire con Unity Collaborate.”

In realtà non è poi così diffcile imparare ad usare Git, come vedrete basteranno pochi passaggi per avere piena padronanza di questo strumento.

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à allacopia 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 di 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 esse 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 o GitLab

Andimao sul sito https://github.com e procediamo alla registrazione.
Nel caso in cui vogliate usate GitLab, dovrete registrarvi allo stesso modo, ovviamente su https://gitlab.com/

Diventare collaboratori di un progetto Git eistente

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 programma 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. Lì appaiono le vostre ultime modifiche effettuate dall’ultimo aggiornamento.
– A quel punto potrete creare un Commit da spedire che conterrà le modifiche che avete apportato al progetto.
– Per creare un Commit vi basta i inserire un nome per il Commit (e se volte, ma non necessariamente, anche una descrizione) e premere su Commit to Master.
– Una volta creato, il Commit esso sarà ancora nel vostro PC, pronto per essere “spedito alla Repository on-line.
– Per spedire il Commit contenente le vostre modifiche, vi basterà premere il pulsante Push, come avete fatto la prima volta.

Nel video di esempio sottostante cambio semplecemente un testo di una UI e spedisco le modifiche alla Repository.
Avrei potuto aver effettuato qualsiasi altra modifica al progetto come inserire nuovi files, aver modificato codice o textures, modelli ecc…

 

– 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 dei servizi gratuiti

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. 😉 

Diventare collaboratori di un progetto Git eistente

Abbiamo visto come iniziare un progetto nuovo su GitHub per gestirlo con GitHub Desktop.
Mettiamo ora il caso che il vostro programmatore di fiducia abbia creato una Repository su GitHub o GitLab e voi vogliate scaricare il progetto così da poter far parte dei collaboratori.

Prendiamo come esempio un progetto su GitLab, ma la procedura sarebbe la stessa anche se il progetto si trovasse su GitHub.

Per diventare collaboratore di un progetto su GitLab saranno necessarie tre cose.

  1. La prima è quella di essere registrati sul sito di GitLab, https://gitlab.com.
  2. Poi, ovviamente è quella di aver scaricato GitHub Desktop da questo sito: https://desktop.github.com
  3. La terza è l’indirizzo HTTPS del progetto.
    Questo ve lo passerà il creatore della Repository.

Come primo passaggio andiamo sul programma GitHub Desktop per aggiungere il nuovo progetto.
Sul menu del programma andiamo su File->Clone Repository….

Nella finestra che si aprirà, scegliamo il pannello URL ed incolliamo l’indirizzo HTTPS della repository.

Il Local Path verrà generato automaticamente, ma potrete modificarlo a vostro piacimento, ma ATTENZIONE a non modificare il nome dell’ultima cartella che deve essere quella preimpostata.

Premete il pulsante Clone ed inizierà il download del progetto.
Finito il download avrete il vostro progetto clonato e sincronizzato con la Repository in rete e potrete usare GitHub Desktop per inviare le vostre modifiche alla Repository.

 
Condividere la Repository

Nel caso siate voi i creatori della Repository e vogliate condividere il progetto con i vostri collaboratori, dovrete aggiungere i membri al progetto per consentirne l’accesso.

Poi dovrete ottenere l’indirizzo HTTPS per comunicarlo agli altri membri del team.
L’indirizzo HTTPS si trovai sul web, nel progetto della Repository.

Copiate l’indirizzo HTTPS che avrà una sintassi tipo “https://gitlab.com/TuoNome/nomeProgetto.git”

8 pensieri su “Usare Git in Unity

  1. E niente… dopo due anni che tentavo vanamente di capirci qualcosa, leggo questo articolo e puff… tutto funziona alla perfezione.
    Oro colato.

  2. A perfect guide. I’ve never found a guide that explained to me GIT so clearly. In one page I understood everything.
    And I’m not Italian. 😉

  3. No dai.
    Veramente la miglior spiegazione di Git che abbia mai letto. Non ho mai usato Git perché tutti mi dicevano che era molto difficile… e in effetti ho trovato molte difficoltà in passato. Poi ho letto questo articolo.
    Da tanto complicato che sembrava l’hai resa accessibile a chiunque. GRAZIE!

Rispondi a Roy Annulla risposta

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