Share
Dit artikel is bedoeld als een definitieve handleiding voor het correct beheren van uw Unity-projecten!
Versiebeheer is een van de belangrijkste hulpmiddelen in het arsenaal van een ontwikkelaar. Hiermee kunt u eenvoudig wijzigingen terugdraaien als u per ongeluk iets breekt, oudere en nieuwere versies van uw code vergelijken om te zien wat er anders is, en teams in staat stellen dezelfde code te gebruiken zonder per ongeluk elkaars werk te overschrijven. Tot voor kort konden alleen Unity Pro-projecten correct worden gecontroleerd. Sinds Unity 3.5 is het nu echter ook mogelijk om projecten met versiebeheer in de gratis versie van Unity te beheren.
Een versiecontrolesysteem, of VCS, houdt wijzigingen bij die u hebt aangebracht in bestanden in de map, ook wel bekend als uw "werkkopie". Deze wijzigingen worden naast de map opgeslagen in een database die een "repository" wordt genoemd. Telkens wanneer u iets in uw werkkopie wijzigt, moet u die wijzigingen in de repository vastleggen. De VCS vergelijkt dan wat zich al in de repository bevindt naar de inkomende wijzigingen en slaat alleen de verschillen op. Dit houdt de repository zo klein mogelijk.
Voor dit project gebruiken we Mercurial, een gedistribueerde VCS. In tegenstelling tot gecentraliseerde VCS-systemen zoals Subversion (SVN), die meestal afhankelijk zijn van een externe repository die is opgeslagen op een server, kan een gedistribueerd VCS lokale repositories, soms "lokale branches" genoemd, rechtstreeks op uw computer hosten. Dit betekent dat u wijzigingen kunt aanbrengen, deze kunt toewijzen aan uw lokale vestiging, ze kunt testen en zelfs kunt weggooien als iets kapot gaat, allemaal zonder uw teamleden te onderwerpen aan uw wijzigingen totdat u weet dat ze perfect zijn. Als je het zeker weet, kun je die wijzigingen "pushen" naar een externe repository zodat je team "kan" trekken naar hun eigen lokale vestigingen..
Een Unity-project vereist bepaalde meta-informatie om te onthouden welke componenten en verbindingen op de verschillende activa zijn ingesteld. Traditioneel werd deze meta-informatie opgeslagen als een reeks binaire bestanden in de map Bibliotheek van een Unity-project. Deze "binaire blob" kan echter niet op de juiste manier worden samengevoegd, dus wijzigingen die door twee mensen worden aangebracht, kunnen over elkaar heen stampen, waardoor dingen in de editor worden verbroken, zelfs als ze verschillende items bewerken.
De oplossing hiervoor is het inschakelen van metabestanden in de projectinstellingen.
Dit zorgt ervoor dat Unity metabestanden maakt naast elk item in de map Project Assets. Wanneer een activum in de editor wordt gewijzigd, rapporteren alleen het activum en het bijbehorende metabestand wijzigingen, in plaats van de volledige bibliotheekmap..
Zowel Windows als OSX hebben Mercurial-installatieprogramma's. Bezoek de Mercurial-website en klik op de grote downloadknop. De site zal automatisch herkennen welk besturingssysteem u gebruikt en het juiste installatieprogramma downloaden.
Pak het installatieprogramma uit en voer het uit. Doorloop alle stappen en het zou zichzelf moeten installeren zonder enige interventie nodig.
Om ervoor te zorgen dat Mercurial correct is geïnstalleerd, opent u een opdrachtregel. In Windows, druk op Begin en typ cmd in het zoekvak. Op OSX, open Spotlight en zoek naar terminal.
Voer op de opdrachtregel het volgende in:
hg .
Er zou een korte lijst met informatie moeten verschijnen, inclusief welke versie van Mercurial u gebruikt, evenals een lijst met veelgebruikte opdrachten. Voer het volgende in om de volledige lijst met opdrachten te krijgen:
hg hulp
En om hulp te krijgen bij een specifieke opdracht, voert u eenvoudigweg de naam in van de opdracht na hulp:
hg help kloon
NOTITIE: Kwantitatieve commando's beginnen altijd met hg, het element voor kwik op het periodiek systeem. Gelukkig is dit stukje slimme naamgeving gebruikt omdat het eenvoudig te typen is.
Het eerste wat we moeten doen is onze projectmap een repository geven.
Voer op de opdrachtregel in:
hg init
Dat is het. Onze map heeft nu een repository en is klaar voor versiebeheer. Als u verborgen bestanden hebt ingeschakeld, ziet u een .hg map is gemaakt in de projectmap. Dit is waar de repository zich bevindt. Als u om welke reden dan ook ooit versiebeheer wilt verwijderen, verwijdert u eenvoudig de .hg map. Uw werkkopie van de bestanden is ongeschonden.
Nu onze projectmap een repository heeft, laten we de status van de repository controleren om te zien wat er is gewijzigd. Mercurial accepteert verkorte opdrachtnamen, dus een van de volgende werkt:
hg status hg stat hg st
Een statusrapport moet komen met een lijst met bestanden, elk met een enkele letter ernaast. In dit geval zullen alle bestanden vraagtekens naast zich hebben. Het vraagteken geeft aan dat het bestand nog niet versiebeheer is in de repository.
| ? | Een bestand dat zich in de werkkopie bevindt maar niet door de repository wordt bijgehouden. |
| ! | Een bestand dat wordt bijgehouden door de repository, maar ontbreekt in de werkkopie. |
| EEN | Een bestand dat sinds de laatste commit aan de repository is toegevoegd. |
| M | Een bestand dat is gewijzigd sinds de laatste commit. |
| R | Een bestand dat is gepland voor verwijdering uit de repository bij de volgende commit. |
We moeten bestanden expliciet aan onze repository toevoegen om Mercurial te laten weten dat ze versiebeheer willen.
Individuele bestanden kunnen worden toegevoegd:
hg voeg mijnbestand.txt toe
Volledige mappen kunnen worden toegevoegd:
hg scripts toevoegen /
Laten we elke niet-versiebestand (met een ? vraagteken in het statusrapport) in één klap door helemaal geen bestandsnaam op te geven:
hg toevoegen
Voer een statuscontrole uit.
hg-status
Alle bestanden die zijn toegevoegd, moeten nu een letter bevatten EEN naast hen, wat aangeeft dat ze zijn toegevoegd aan de repository en nu worden bijgehouden door Mercurial.
Nu we Mercurial hebben verteld over welke bestanden we versiebeheer willen hebben, moeten we ze toewijzen aan de repository. Elke commit is als een momentopname bekend als een revisie, die de verschillen tussen de vorige revisies en de huidige bijhoudt.
Er zijn twee delen voor elke commit, een bericht en uw gebruikersnaam. De boodschap is dat je beschrijft wat je hebt gedaan, maar houd het kort en krachtig. De gebruikersnaam is slechts een ID om iedereen die de repository mogelijk gebruikt, te laten weten wie bepaalde wijzigingen heeft aangebracht. De gebruikersnaam is ingesteld met de -u vlag en het bericht is ingesteld met de -m vlag:
hg commit -u ian -m "initiaal"
Om te controleren of de commit succesvol was, moeten we het logboek controleren:
hg log
Controleer de status om er zeker van te zijn dat er geen wijzigingen meer zijn.
hg-status
Een leeg statusrapport betekent dat alles naar behoren is vastgelegd.
NOTITIE: Het wordt aanbevolen dat u vaak committeert. Elke commit moet zo 'atomisch' mogelijk zijn. Dat wil zeggen, het zou gemakkelijk beschreven kunnen worden door een eenvoudige uitdrukking zoals "verhoogde spronghoogte van de speler". Als je merkt dat je "en" of komma's in je commit-berichten moet gebruiken, dan is het waarschijnlijk tijd om twee afzonderlijke commits te maken. De reden hiervoor is om het eenvoudig te maken specifieke wijzigingen terug te draaien die u hebt aangebracht wanneer u problemen ondervindt.
Er zijn twee belangrijke manieren om fouten te herstellen: een rollback of een revert. Een terugdraaibeurt maakt het laatste commando ongedaan dat je hebt ingevoerd en is ideaal voor het oplossen van spelfouten in je commit-berichten of over ijverig toevoegen.
hg rollback
Voer een statuscontrole uit om te controleren of alles correct is teruggedraaid.
hg-status
Een terugzetting is krachtiger, waardoor u in de loop van de tijd door verschillende revisies kunt reizen, voor het geval u een aantal wijzigingen die u heeft aangebracht, moet terugnemen. Om te weten welke revisie u wilt terugzetten, moet u eerst het logboek controleren:
hg log
Het nummer of de hash kan worden gebruikt om naar een specifieke revisie te verwijzen terwijl deze wordt teruggezet. Het nummer is specifiek voor uw repository, omdat de branch van iemand anders mogelijk meer wijzigingen heeft, zodat de cijfers anders zijn. De hash is universeel, dit betekent dat iedereen kan terugkeren naar een specifieke revisie op een gedeelde repository door die hash-reeks te gebruiken.
Om terug te keren naar een specifieke revisie, moeten we het revisienummer opgeven met behulp van de -r vlag. We moeten Mercurial ook vertellen om "alles terug te zetten" met behulp van de -een vlag. Ten slotte moeten we tegen Mercurial zeggen dat we niet willen dat het back-upbestanden maakt met behulp van de --no-backup vlag.
hg revert -r 0 -a --no-backup
Voer een statuscontrole uit om te controleren of alles correct is teruggezet.
hg-status
NOTITIE: Als u de. Weglaat --no-backup vlag, zal Mercurial back-upbestanden maken voor alle bestanden die worden beïnvloed door de terugzetprocedure. Deze back-upbestanden hebben allemaal een .orig uitbreiding. Vergeet niet toe te voegen .orig bestanden.
Nu we onze fout ongedaan hebben gemaakt, laten we ervoor zorgen dat het niet opnieuw gebeurt. We willen de mappen Library en Temp permanent negeren, zodat deze niet per ongeluk kunnen worden toegevoegd de volgende keer dat we triggertoegang krijgen met het commando 'Toevoegen'.
Mercurial gebruikt een speciaal bestand met de naam .hgignore om de namen op te slaan van bestanden en mappen die u permanent wilt negeren. Dit bestand gaat rechtstreeks in je projectmap en wordt net als al het andere gecontroleerd. Dit zorgt ervoor dat iedereen die de repo gebruikt deze niet per ongeluk kan vervuilen met ongewenste bestanden.
Gebruik uw favoriete teksteditor om het volgende in te voeren:
syntaxis: glob Bibliotheek Temp * .pidb * .sln * .userprefs * .csprog * .orig
Dit vertelt Mercurial wat we shell-style syntaxis (ook bekend als "glob" -syntaxis) willen gebruiken om de mappen Library en Temp te negeren, verschillende tijdelijke bestanden die MonoDevelop maakt te negeren en te negeren .orig bestanden voor het geval we ze per ongeluk maken bij het terugzetten.
Sla het bestand op in de hoofdmap van uw projectmap als .hgignore (let op de stip aan het begin). Voer vervolgens nog een statuscontrole uit:
hg-status
De .hgignore bestand zou nu moeten worden vermeld in het statusrapport, maar de bibliotheekmap, map Temp en andere genegeerde bestanden zouden dat niet moeten doen. We kunnen dus veilig het add-commando gebruiken zonder de exacte bestandsnamen te gebruiken en vervolgens de resultaten vastleggen.
hg add hg commit -u ian -m "Initial"
Controleer het logboek om te controleren of de commit succesvol was.
hg log
NOTITIE: Meer informatie over hgignore-bestanden vindt u hier.
Als u uw repository met andere ontwikkelaars wilt delen, is de eenvoudigste manier om een externe repository op een server te maken en uw wijzigingen daarin aan te passen.
Het eerste dat je moet doen is een Mercurial-host vinden. Er zijn er verschillende waaronder BitBucket en Kiln; Beide hebben gratis accounts voor kleine teams. In ons geval gebruiken we BitBucket, maar beide services werken in essentie hetzelfde. Zodra u zich bij een van de services voor een account hebt aangemeld, moet u een nieuwe repository maken met behulp van hun webinterface.
Eenmaal gemaakt, zoekt u naar het "kloonpad". Het zou er ongeveer zo uit moeten zien:
hg clone https://bitbucket.org/username/reponame
Normaal gesproken zou deze opdracht worden gebruikt om een lokale kopie van de repository te maken. Maar we hebben al een lokale repository en we willen er in plaats daarvan veranderingen van naar de externe repository sturen. Om dit te doen, kunnen we het URL-adres aan het einde van de kloonreeks nemen en gebruiken als de bestemming voor de push-opdracht.
hg push https://bitbucket.org/username/reponame
Mercurial vergelijkt de lokale repository met de externe repository om te zien hoe ze verschillen. Het zal zien dat onze lokale repository nieuwere wijzigingen bevat die de externe repository mist en ze naar de externe repository zal sturen.
Het zal echter eerst om een gebruikersnaam en een wachtwoord vragen. Deze moeten overeenkomen met de gebruikersnaam / e-mailadres en het wachtwoord waarmee u zich bij de host-service hebt aangemeld.
Mercurial moet melden dat alle wijzigingen met succes zijn doorgevoerd en dat betekent dat iedereen die afhankelijk is van uw repository er nu uit kan "trekken" om uw wijzigingen te ontvangen. Ten eerste zullen ze de repository moeten klonen om een lokale kopie te maken.
hg clone https://bitbucket.org/username/reponame
En trek vervolgens alle wijzigingen aan die u of iemand anders na verloop van tijd maakt:
hg trekken
U moet dan een "update" uitvoeren om ervoor te zorgen dat uw werkkopie wordt bijgewerkt:
hg update
Maar om tijd te besparen, kunt u de pull doen en alles tegelijk bijwerken met behulp van de -u vlag:
hg pull -u
NOTITIE: Mercurial zal u vragen wanneer een binair bestand wordt bijgewerkt of samengevoegd. Tenzij u zeker weet dat u wijzigingen hebt aangebracht in lokale binaire bestanden, kiest u altijd de "(O) andere" optie in plaats van de "(L) okale" keuze.
Er zijn verschillende vervelende aspecten bij het steeds maar weer opnieuw geven van dezelfde commando's, zoals het onthouden om een gebruikersnaam te leveren bij het plegen, elke keer dat je pusht, een wachtwoord in te voeren enz. Veel van deze instellingen kunnen worden opgeslagen in wat bekend staat als een hgrc het dossier. Om een te maken hgrc bestand, gebruik je favoriete teksteditor en voer het volgende in:
[paths] default = https://bitbucket.org/username/reponame
Dit vertelt Mercurial welk pad standaard moet worden gebruikt voor push- en pull-opdrachten. Vervang dit nep-adres door het echte adres in uw externe repository. Voer vervolgens het volgende in:
[ui] gebruikersnaam = Voornaam Achternaam
Dit vertelt Mercurial welke gebruikersnaam standaard moet worden gebruikt bij het plegen. Vervang dit opnieuw door uw juiste inloggegevens en zorg ervoor dat het e-mailadres overeenkomt met het adres waarmee u zich heeft aangemeld. Tot slot, voer in:
[auth] host.prefix = bitbucket.org host.username = gebruikersnaam host.password = wachtwoord host.schemes = http https
Dit vertelt Mercurial welke referenties moeten worden gebruikt bij het doorsturen naar een beveiligde externe repository, zodat u niet telkens een gebruikersnaam en wachtwoord hoeft in te voeren wanneer u pusht of trekt. Zorg ervoor dat u het voorvoegsel vervangt door het kortst mogelijke deel van het adres van uw gastheer en niet het http: // protocol in het voorvoegsel. Vervang vervolgens de gebruikersnaam en het wachtwoord door degene waarmee je je hebt aangemeld bij je host. Het schema vertelt Mercurial aan welke protocollen een verbinding moet worden gemaakt.
Bewaar het bestand als laatste hgrc (zonder punt of extensie aan het einde) binnen de .hg map in uw repository. U hoeft niet langer handmatig gebruikersnamen, wachtwoorden of paden te geven wanneer u vanaf nu opdrachten geeft.
Versiebeheer lijkt misschien een beetje intimiderend voor niet-ingewijden, maar de moeite is de moeite waard. Het geeft je gemoedsrust om te weten dat je op elk moment een kapot project terug kunt draaien naar een punt waar het eerder werkte. Op dezelfde manier betekent het gebruik van externe opslagplaatsen dat code niet alleen kan worden gedeeld met teamleden, maar dat het herstellen van uw project nadat er iets catastrofaal gebeurt (zoals een storing op de harde schijf) eenvoudig is.
Voor meer informatie over gedistribueerd versiebeheer en Mercurial, raad ik ten zeerste aan om Hg Init te bezoeken. Het bevat een reeks artikelen waarin de manier waarop versiebeheer en Mercurial-functies worden uitgelegd, uitgebreid wordt uitgelegd. Het is kort, zeer informatief, gemakkelijk te lezen, gemakkelijk te begrijpen en zelfs een beetje grappig.
Accentsconagua