Share
Questo articolo è pensato per essere una guida definitiva su come controllare correttamente la versione dei tuoi progetti Unity!
Il controllo della versione è uno degli strumenti più importanti nell'arsenale di qualsiasi sviluppatore. Ti consente di ripristinare facilmente le modifiche se accidentalmente rompi qualcosa, confronta le versioni precedenti e più recenti del tuo codice per vedere cosa è diverso e consente ai team di lavorare sullo stesso codice senza sovrascrivere accidentalmente il lavoro degli altri. Fino a poco tempo fa, solo i progetti Unity Pro potevano essere controllati in modo appropriato. Tuttavia, da Unity 3.5, ora è possibile anche i progetti di controllo delle versioni nella versione gratuita di Unity.
Un sistema di controllo della versione, o VCS, tiene traccia delle modifiche apportate ai file nella cartella, nota anche come "copia di lavoro". Queste modifiche sono memorizzate insieme alla cartella in un database noto come "repository". Ogni volta che si modifica qualcosa nella propria copia di lavoro, è necessario trasferire tali modifiche al repository. Il VCS confronta quindi ciò che è già presente nel repository con le modifiche in entrata e memorizza solo le differenze. Ciò mantiene il repository il più piccolo possibile.
Per questo progetto, useremo Mercurial che è un VCS distribuito. A differenza dei sistemi VCS centralizzati come Subversion (SVN), che tipicamente si basano su un repository remoto memorizzato su un server, un VCS distribuito può ospitare repository locali, a volte chiamati "rami locali", direttamente sul tuo computer. Ciò significa che puoi apportare modifiche, assegnarle alla tua filiale locale, metterle alla prova e persino scartarle se qualcosa si rompe, tutto senza dover sottoporre i membri del tuo team alle tue modifiche finché non sai che sono perfette. Una volta che sei sicuro, puoi "spingere" queste modifiche su un repository remoto affinché il tuo team "tiri" nelle proprie filiali locali.
Un progetto Unity richiede determinate meta-informazioni per ricordare quali componenti e connessioni sono impostati sulle varie risorse. Tradizionalmente, questa meta informazione era memorizzata come un insieme di file binari nella cartella Libreria di un progetto Unity. Tuttavia, questo "binario blob" non può essere unito correttamente, quindi le modifiche apportate da due persone potrebbero schiacciare l'una sull'altra, causando l'interruzione delle cose nell'editor, anche se stavano modificando asset diversi.
La soluzione a questo è di attivare Meta Files nelle impostazioni del progetto.
Questo farà sì che Unity crei meta file accanto a ogni risorsa nella cartella Risorse del progetto. Ora, quando una risorsa viene modificata nell'editor, solo la risorsa e il relativo file meta associato riporteranno le modifiche, anziché l'intera cartella Libreria.
Sia Windows che OSX hanno installer Mercurial. Visita il sito Web Mercurial e fai clic sul grande pulsante di download. Il sito riconosce automaticamente il sistema operativo che stai utilizzando e scarica il programma di installazione appropriato.
Decomprimere il programma di installazione ed eseguirlo. Fare clic su tutti i passaggi e dovrebbe installarsi senza alcun intervento necessario.
Per assicurarsi che Mercurial sia installato correttamente, apri una riga di comando. Su Windows, premere Inizio e scrivi cmd nella casella di ricerca. Su OSX, aperto Riflettore e cercare terminale.
Sulla riga di comando, inserisci:
hg .
Dovrebbe apparire un breve elenco di informazioni, tra cui la versione di Mercurial che stai utilizzando e un elenco di comandi comuni. Per ottenere l'elenco completo dei comandi, inserisci:
hg aiuto
E per ottenere aiuto su un comando specifico, inserisci semplicemente il nome del comando dopo l'aiuto:
hg help clone
NOTA: Comandi mercuriali iniziano sempre con hg, l'elemento per il mercurio nella tavola periodica. Per fortuna, questo bit di nomi intelligente è stato usato perché è facile da digitare.
La prima cosa che dobbiamo fare è dare alla nostra cartella del progetto un repository.
Nella riga di comando, inserisci:
hg init
Questo è tutto. La nostra cartella ora ha un repository ed è pronta per il controllo della versione. Se hai attivato i file nascosti, noterai un .hg cartella è stata creata nella cartella del progetto. Questo è dove risiede il repository. Se, per qualche motivo, desideri rimuovere il controllo della versione, cancella semplicemente .hg cartella. La tua copia di lavoro dei file sarà illeso.
Ora che la nostra cartella del progetto ha un repository, controlliamo lo stato del repository per vedere cosa è cambiato. Mercurial accetterà i nomi dei comandi abbreviati, quindi funzionerà una delle seguenti operazioni:
hg status hg stat hg st
Un rapporto sullo stato dovrebbe venire con un elenco di file, ciascuno con una singola lettera accanto a loro. In questo caso, tutti i file avranno punti interrogativi accanto a loro. Il punto interrogativo indica che il file non è ancora controllato in versione nel repository.
| ? | Un file che si trova nella copia di lavoro ma non tracciato dal repository. |
| ! | Un file che viene tracciato dal repository ma manca nella copia di lavoro. |
| UN | Un file che è stato aggiunto al repository dall'ultimo commit. |
| M | Un file che è stato modificato dall'ultimo commit. |
| R | Un file che è previsto per la rimozione dal repository sul prossimo commit. |
Abbiamo bisogno di aggiungere esplicitamente file al nostro repository per far sapere a Mercurial che vogliamo che siano controllati dalla versione.
È possibile aggiungere singoli file:
hg aggiungi myfile.txt
È possibile aggiungere intere cartelle:
hg aggiungi script /
Aggiungiamo ogni singolo file non versione (con a ? punto interrogativo nel rapporto di stato) in un colpo solo non specificando alcun nome di file:
hg add
Esegui un controllo di stato.
hg status
Tutti i file che sono stati aggiunti dovrebbero ora avere una lettera UN accanto a loro, che indica che sono stati aggiunti al repository e ora vengono monitorati da Mercurial.
Ora che abbiamo detto a Mercurial quali file vogliamo essere controllati dalla versione, dobbiamo impegnarli nel repository. Ogni commit è come un'istantanea nota come revisione, che tiene traccia delle differenze tra le revisioni precedenti e quella corrente.
Ci sono due parti per ogni commit, un messaggio e il tuo nome utente. Il messaggio è dove puoi descrivere ciò che hai fatto, ma mantienilo breve e dolce. Il nome utente è solo un identificatore per consentire a chiunque altro possa utilizzare il repository di sapere chi ha apportato determinate modifiche. Il nome utente è impostato con -u flag e il messaggio è impostato con -m bandiera:
hg commit -u ian -m "iniziale"
Per assicurarti che il commit abbia avuto successo, dobbiamo controllare il registro:
hg log
Per essere doppiamente sicuro, controlla lo stato per assicurarti che non rimangano cambiamenti.
hg status
Un rapporto di stato vuoto significa che tutto è stato correttamente commesso.
NOTA: Si raccomanda di impegnarsi spesso. Ogni commit dovrebbe essere il più "atomico" possibile. Cioè, dovrebbe essere facilmente descritto da una frase semplice come "aumento dell'altezza di salto del giocatore". Se ti ritrovi a dover usare "e" o virgole nei tuoi messaggi di commit, allora è probabilmente il momento di fare due commit separati. La ragione di ciò è semplificare il rollback delle modifiche specifiche apportate quando si riscontrano problemi.
Esistono due modi principali per correggere gli errori: un rollback o un ripristino. Un rollback annullerà l'ultimo comando immesso che è l'ideale per correggere errori di ortografia nei messaggi di commit o per aggiungere zelante.
hg rollback
Esegui un controllo di stato per assicurarti che tutto sia stato ripristinato correttamente.
hg status
Un ripristino è più potente, permettendoti di viaggiare indietro nel tempo attraverso diverse revisioni, nel caso in cui hai bisogno di uscire da diverse modifiche che hai fatto. Per scoprire quale revisione desideri ripristinare prima devi controllare il registro:
hg log
È possibile utilizzare il numero o l'hash per fare riferimento a una revisione specifica durante il ripristino. Il numero è specifico per il tuo repository dal momento che il ramo di qualcun altro potrebbe avere più modifiche in modo che i loro numeri siano diversi. L'hash è universale, questo significa che chiunque potrebbe ripristinare una revisione specifica su un repository condiviso usando quella stringa di hash.
Per ripristinare una revisione specifica, è necessario specificare il numero di revisione utilizzando il comando -r bandiera. Dobbiamo anche dire a Mercurial di "ripristinare tutto" usando il -un bandiera. Infine, dobbiamo dire a Mercurial che non vogliamo che crei alcun file di backup usando il --no-backup bandiera.
hg revert -r 0 -a --no-backup
Esegui un controllo di stato per assicurarti che tutto sia stato ripristinato correttamente.
hg status
NOTA: Se ometti il --no-backup flag, Mercurial creerà i file di backup per tutti i file interessati dalla procedura di ripristino. Questi file di backup avranno tutti un .orig estensione. Assicurati di non aggiungere .orig File.
Ora che abbiamo annullato il nostro errore, assicuriamoci che non accada di nuovo. Vogliamo ignorare in modo permanente le cartelle Libreria e Temp in modo che non possa essere aggiunto accidentalmente la prossima volta che otteniamo il trigger con il comando add..
Mercurial utilizza un file speciale chiamato .hgignore per memorizzare i nomi dei file e delle cartelle che si desidera ignorare in modo permanente. Questo file va direttamente nella cartella del tuo progetto ed è controllato dalla versione come qualsiasi altra cosa. Ciò garantisce che chiunque utilizzi il repository non possa inquinarlo accidentalmente con file indesiderati.
Usando il tuo editor di testo preferito per inserire quanto segue:
sintassi: glob Library Temp * .pidb * .sln * .userprefs * .csprog * .orig
Questo dice a Mercurial che cosa vogliamo usare la sintassi shell-style (conosciuta come sintassi "glob") per ignorare le cartelle Library e Temp, ignorare diversi file temporanei creati da MonoDevelop e ignorare .orig file nel caso in cui li creiamo accidentalmente durante il ripristino.
Salva il file nella cartella principale della tua cartella del progetto come .hgignore (annotando il punto all'inizio). Quindi esegui un altro controllo dello stato:
hg status
Il .hgignore il file dovrebbe ora essere elencato nel rapporto di stato, ma la cartella Libreria, la cartella Temp e altri file ignorati non dovrebbero. Quindi possiamo tranquillamente utilizzare il comando add senza la necessità di usare nomi di file esatti e quindi confermare i risultati.
hg add hg commit -u ian -m "Iniziale"
Controlla il log per assicurarti che il commit sia andato a buon fine.
hg log
NOTA: Ulteriori informazioni sui file hgignore sono disponibili qui.
Se si desidera condividere il repository con altri sviluppatori, il modo più semplice è creare un repository remoto su un server e inviare le modifiche a tale.
La prima cosa che devi fare è trovare un host Mercurial. Diversi esistono tra cui BitBucket e Kiln; Entrambi hanno account gratuiti per piccole squadre. Nel nostro caso, useremo BitBucket, ma entrambi i servizi funzionano sostanzialmente allo stesso modo. Dopo aver registrato un account su entrambi i servizi, assicurarsi di creare un nuovo repository usando la loro interfaccia web.
Una volta creato, cerca il "percorso clone". Dovrebbe assomigliare a qualcosa di simile a questo:
hg clone https://bitbucket.org/username/reponame
Normalmente, questo comando verrebbe utilizzato per creare una copia locale del repository. Ma abbiamo già un repository locale e vogliamo invece inviare le modifiche da esso al repository remoto. Per fare ciò, possiamo prendere l'indirizzo URL alla fine della stringa clone e usarlo come destinazione per il comando push.
hg push https://bitbucket.org/username/reponame
Mercurial confronterà il repository locale con il repository remoto per vedere come differiscono. Vedrà che il nostro repository locale ha modifiche più recenti che il repository remoto è mancante e le invierà al repository remoto.
Tuttavia, verrà prima richiesto un nome utente e una password. Questi dovrebbero corrispondere al nome utente / email e alla password che hai registrato al servizio host con.
Mercurial dovrebbe segnalare che tutte le modifiche sono state spinte con successo e ciò significa che chiunque dipende dal proprio repository può ora "tirare" da esso per ricevere le modifiche. In primo luogo, dovranno clonare il repository per creare una copia locale.
hg clone https://bitbucket.org/username/reponame
E poi estrai le modifiche che tu o chiunque altro fate col passare del tempo:
hg pull
Dovrai quindi eseguire un "aggiornamento" per assicurarti che la tua copia di lavoro sia aggiornata:
aggiornamento hg
Ma per risparmiare tempo, puoi fare il pull e aggiornare tutto in una volta usando il -u bandiera:
hg pull -u
NOTA: Mercurial ti chiederà ogni volta che un file binario viene aggiornato o unito. A meno che non si sia certi di aver apportato modifiche ai file binari locali, scegliere sempre il "(O) altri" opzione al posto di "(Locale" opzione.
Ci sono molti aspetti noiosi per emettere gli stessi comandi più e più volte, come dover ricordare di fornire un nome utente quando si esegue il commit, dover digitare una password ogni volta che si preme, ecc. Molte di queste impostazioni possono essere memorizzate in ciò che è noto come un hgrc file. Per creare un hgrc file, usa il tuo editor di testo preferito e inserisci quanto segue:
[paths] default = https://bitbucket.org/username/reponame
Questo indica a Mercurial quale percorso utilizzare per impostazione predefinita per i comandi push e pull. Assicurati di sostituire questo indirizzo falso con l'indirizzo reale nel tuo repository remoto. Quindi, inserisci quanto segue:
[ui] username = Firstname Lastname
Questo indica a Mercurial quale nome utente utilizzare per impostazione predefinita durante il commit. Ancora una volta, sostituisci questo con le tue credenziali corrette e assicurati che l'indirizzo email corrisponda a quello con cui ti sei registrato. Infine, inserisci:
[auth] host.prefix = bitbucket.org host.username = nomeutente host.password = password host.schemes = http https
Questo dice a Mercurial quali sono le credenziali da usare quando si preme su un repository remoto sicuro in modo da non dover inserire un nome utente e una password ogni volta che si spinge o si tira. Assicurati di sostituire il prefisso con la parte più breve possibile dell'indirizzo del tuo host e non includere il http: // protocollo nel prefisso o. Quindi, sostituisci il nome utente e la password con quello con cui ti sei registrato al tuo host. Lo schema dice a Mercurial quali protocolli tentare di connettersi.
Infine, salva il file come hgrc (senza punto o estensione alla fine) dentro il .hg cartella nel tuo repository. Non è più necessario assegnare manualmente nomi utente, password o percorsi quando si eseguono i comandi da ora in poi.
Il controllo della versione può sembrare un po 'scoraggiante per i non addetti ai lavori, ma lo sforzo è utile. Ti dà la tranquillità di sapere che in qualsiasi momento puoi riportare un progetto rotto a un punto in cui funzionava prima. Allo stesso modo, l'uso di repository remoti significa che il codice non può essere condiviso solo con i membri del team, ma il ripristino del progetto dopo un evento catastrofico (come un guasto del disco rigido) è facile.
Per ulteriori informazioni sul controllo della versione distribuita e su Mercurial, consiglio vivamente di visitare Hg Init. Ha una serie di articoli che spiegano in dettaglio le pratiche di controllo della versione e le caratteristiche di Mercurial. È breve, altamente informativo, facile da leggere, facile da capire e anche un po 'divertente.
Accentsconagua