Share
Den här artikeln är avsedd att vara en slutgiltig guide för hur man korrekt version ska styra dina Unity-projekt!
Versionskontroll är ett av de viktigaste verktygen i någon utvecklarens arsenal. Det gör att du enkelt kan rulla tillbaka ändringar om du oavsiktligt bryter mot något, jämför äldre och nyare versioner av koden för att se vad som är annorlunda och det tillåter att lag arbetar med samma kod utan att oavsiktligt skriva över varandras arbete. Fram till nyligen kunde endast Unity Pro-projekt vara korrekt versionskontrollerade. Men, sedan Unity 3.5, är det nu möjligt att versionera kontrollprojekt i den fria versionen av Unity också.
Ett versionsstyrningssystem, eller VCS, håller reda på ändringar du har gjort i filer i mappen, även känd som din "arbets kopia". Dessa ändringar lagras vid sidan av mappen i en databas som kallas "förvar". Varje gång du ändrar något i din arbetsskopia måste du begå ändringarna i förvaret. VCS jämför sedan vad som redan finns i förvaret till de inkommande ändringarna och lagrar endast skillnaderna. Detta håller förvaret så liten som möjligt.
För detta projekt använder vi Mercurial som är en distribuerad VCS. Till skillnad från centraliserade VCS-system som Subversion (SVN), som vanligtvis är beroende av ett fjärrförvar som är lagrat på en server, kan en distribuerad VCS vara värd för lokala repositorier, ibland kallade "lokala filialer", direkt på din dator. Det innebär att du kan göra ändringar, begära dem till din lokala filial, testa dem och till och med förkasta dem om något bryter, allt utan att du måste utsätta dina lagmedlemmar för dina ändringar tills du vet att de är perfekta. När du är säker kan du "trycka" de ändringarna till ett fjärrförråd för att laget ska kunna "dra" till sina egna lokala grenar.
Ett Unity-projekt kräver viss metainformation för att komma ihåg vilka komponenter och anslutningar som ställs på de olika tillgångarna. Traditionellt lagrades denna metainformation som en uppsättning binära filer i bibliotekets mapp för ett Unity-projekt. Denna "binära blob" kan emellertid inte sammanfogas ordentligt, så ändringar som görs av två personer kan stampa över varandra och orsaka att saker bryts i redigeraren, även om de redigerar olika tillgångar.
Lösningen på detta är att slå på Meta Files i projektinställningarna.
Detta kommer att leda till att Unity skapar metafiler utöver varje tillgång i mappen Project Assets. Nu när en tillgång ändras i redigeraren kommer endast tillgången och den associerade metafilen att rapportera ändringar i stället för hela bibliotekets mapp.
Både Windows och OSX har Mercurial installatörer. Besök Mercurial hemsida och klicka på den stora nedladdningsknappen. Webbplatsen kommer automatiskt att känna igen vilket operativsystem du använder och hämta det lämpliga installationsprogrammet.
Unzip installatören och kör den. Klicka igenom alla steg och det ska installera sig själv utan att behöva ingripa.
För att säkerställa att Mercurial installeras korrekt, öppna en kommandorad. På Windows trycker du på Start och typ cmd i sökrutan. På OSX, öppna Strålkastare och söka efter terminal.
På kommandoraden skriver du in:
hg .
En kort lista med information ska visas inklusive vilken version av Mercurial du använder, samt en lista med vanliga kommandon. För att få den fullständiga listan med kommandon, ange:
hg hjälp
Och för att få hjälp med ett visst kommando, skriv helt enkelt kommandot namn efter hjälp:
hg hjälp klon
NOTERA: Mercurialkommandon börjar alltid med hg, elementet för kvicksilver på det periodiska bordet. Lyckligtvis användes den här smarta namnet eftersom det är lätt att skriva.
Det första vi behöver göra är att ge vår projektmapp ett repository.
På kommandoraden skriver du in:
hg init
Det är allt. Vår mapp har nu ett förråd och är redo för versionskontroll. Om du har dolda filer aktiverade märker du en .hg mappen har skapats i projektmappen. Det här är varför förvaret finns. Om du av någon anledning vill ta bort versionskontroll, raderar du helt enkelt .hg mapp. Din arbetskopia av filerna kommer att vara oskadd.
Nu när vår projektmapp har ett repository, låt oss kolla lagrets status för att se vad som ändrats. Mercurial kommer att acceptera förkortade kommandonamn, så något av följande kommer att fungera:
hg status hg stat hg st
En statusrapport ska komma med en lista med filer, var och en med ett bokstav bredvid dem. I det här fallet kommer alla filer att ha frågetecken bredvid dem. Frågetecknet anger att filen inte är versionskontrollerad i förvaret än.
| ? | En fil som finns i arbetskopia men som inte spåras av förvaret. |
| ! | En fil som spåras av förvaret men saknas i arbetsexemplet. |
| en | En fil som har lagts till förvaret sedan det senaste åtagandet. |
| M | En fil som har ändrats sedan det senaste åtagandet. |
| R | En fil som är slated för borttagning från förvaret vid nästa commit. |
Vi måste uttryckligen lägga till filer i vårt förråd för att låta Mercurial veta att vi vill att de ska vara versionskontrollerade.
Individuella filer kan läggas till:
hg lägg till myfile.txt
Hela mappar kan läggas till:
hg lägg till skript /
Låt oss lägga till varje enskild version utan version (med en ? frågetecken i statusrapporten) i ett fall genom att inte ange något filnamn alls:
hg lägg till
Utför en statuskontroll.
hg status
Alla filer som lagts till borde nu ha ett brev en bredvid dem, vilket indikerar att de har lagts till förvaret och spåras nu av Mercurial.
Nu när vi har meddelat Mercurial vilka filer vi vill vara versionskontrollerade, måste vi begå dem till förvaret. Varje förpliktelse är som en ögonblicksbild som kallas en revision, som håller reda på skillnaderna mellan de tidigare revisionerna och den aktuella.
Det finns två delar till något engagemang, ett meddelande och ditt användarnamn. Meddelandet är där du får beskriva vad du gjorde, men håll det kort och sött. Användarnamnet är bara en identifierare för att låta någon annan som kanske använder förvaret veta vem gjorde vissa ändringar. Användarnamnet är inställt med -u flaggan och meddelandet är inställt med -m flagga:
hg commit -u ian -m "initial"
För att säkerställa att fördraget var framgångsrikt måste vi kontrollera loggen:
hg logg
För att vara dubbelvis säker, kontrollera statusen för att se till att inga ändringar kvarstår.
hg status
En tom statusrapport betyder att allt var korrekt engagerat.
NOTERA: Det rekommenderas att du begår ofta. Varje engagemang bör vara så "atomiskt" som möjligt. Det vill säga det ska lätt beskrivas med en enkel fras som "ökad spelarens hopphöjd". Om du tycker att du behöver använda "och" eller kommatecken i dina begå budskap, så är det nog dags att göra två separata förpliktelser. Anledningen till detta är att göra det enkelt att rulla tillbaka specifika ändringar du har gjort när du stöter på problem.
Det finns två viktiga sätt att åtgärda misstag: en återgång eller en återställning. En återuppringning kommer att ångra det sista kommandot du skrev in som är idealiskt för att fastställa stavfel i dina begå budskap eller över elak.
hg rollback
Utför en statuskontroll för att se till att allt har rullats tillbaka korrekt.
hg status
En återställning är kraftfullare, så att du kan resa tillbaka i tid genom flera ändringar, om du behöver backa upp flera ändringar du har gjort. För att få reda på vilken revision du vill återvända till måste du först kontrollera loggen:
hg logg
Antingen kan numret eller hash användas för att hänvisa till en specifik revision vid återställning. Numret är specifikt för ditt förråd eftersom någon annans gren kan ha fler ändringar så att deras nummer skulle vara annorlunda. Hasan är universell, det vill säga att någon kan återgå till en specifik revision på ett gemensamt förråd genom att använda den hash-strängen.
För att återgå till en specifik revision måste vi ange revisionsnumret med hjälp av -r flagga. Vi måste också berätta Mercurial att "återgå allt" med hjälp av -en flagga. Slutligen måste vi berätta Mercurial att vi inte vill att den ska skapa några backupfiler med hjälp av --no-backup flagga.
hg återgå -r 0-a -no-backup
Utför en statuskontroll för att försäkra dig om att allting återställs korrekt.
hg status
NOTERA: Om du släpper bort --no-backup flagg kommer Mercurial att skapa backupfiler för alla filer som påverkas av återställningsförfarandet. Dessa säkerhetskopieringsfiler kommer alla att ha en .orig förlängning. Var noga med att inte lägga till .orig filer.
Nu när vi har ångrat vårt misstag, låt oss se till att det inte händer igen. Vi vill permanent ignorera bibliotekets och Temp-mapparna så att det inte kan läggas till av misstag nästa gång vi blir utlösare lyckliga med kommandot lägga till.
Mercurial använder en speciell fil som heter .hgignore för att lagra namnen på filer och mappar som du vill ignorera permanent. Den här filen går precis in i din projektmapp och är versionskontrollerad precis som allt annat. Detta säkerställer att alla som använder repo kan inte oavsiktligt förorena det med oönskade filer.
Använd din favorit textredigerare för att ange följande:
syntax: glob Bibliotek Temp * .pidb * .sln * .userprefs * .csprog * .orig
Detta berättar Mercurial vad vi vill använda skalstilsyntax (känd som "glob" -syntax) för att ignorera mapparna Bibliotek och Temp, ignorera flera temporära filer som MonoDevelop skapar och att ignorera .orig filer bara om vi av misstag skapar dem när du återgår.
Spara filen i roten till din projektmapp som .hgignore (notera punkten i början). Gör sedan en annan statuskontroll:
hg status
De .hgignore filen ska nu anges i statusrapporten, men bibliotekets mapp, Temp-mapp och andra ignorerade filer ska inte. Så vi kan säkert använda add-kommandot utan att behöva använda exakta filnamn och sedan begå resultaten.
hg lägg till hg commit -u ian -m "Initial"
Kontrollera loggen för att försäkra sig om att det var framgångsrikt.
hg logg
NOTERA: Mer information om hgignore-filer finns här.
Om du vill dela ditt förråd med andra utvecklare är det enklaste sättet att skapa ett fjärrförvar på en server och driva dina ändringar till det.
Det första du behöver göra är att hitta en Mercurial värd. Flera finns inklusive BitBucket och Kiln; Båda har gratis konton för små lag. I vårt fall använder vi BitBucket, men båda tjänsterna fungerar i stort sett desamma. När du har registrerat dig för ett konto på endera tjänsten, var noga med att skapa ett nytt förråd med hjälp av deras webbgränssnitt.
När du väl skapat, leta efter "klonbanan". Det borde se ut så här:
hg klon https://bitbucket.org/username/reponame
Normalt skulle detta kommando användas för att skapa en lokal kopia av förvaret. Men vi har redan ett lokalt förråd och vi vill istället skicka ändringar från det till fjärrförvaret. För att göra detta kan vi ta URL-adressen till slutet av klonsträngen och använda den som destination för push-kommandot.
hg tryck https://bitbucket.org/username/reponame
Mercurial kommer att jämföra det lokala förvaret till fjärrförvaret för att se hur de skiljer sig åt. Det kommer att se att vårt lokala förråd har nya ändringar som fjärrförvaret saknas och skickar dem till fjärrförvaret.
Det kommer emellertid först att fråga om ett användarnamn och ett lösenord. Dessa ska motsvara användarnamnet / e-postadressen och lösenordet du registrerade dig för värdtjänsten med.
Mercurial bör rapportera att alla ändringar har skett med framgång och det betyder att den som beror på ditt förråd kan nu "dra" från det för att få dina ändringar. Först måste de klona förvaret för att göra en lokal kopia.
hg klon https://bitbucket.org/username/reponame
Och sedan dra några ändringar som du eller någon annan gör när tiden går vidare:
hg pull
Då måste du göra en "uppdatering" för att se till att din arbets kopia uppdateras:
hg uppdatering
Men för att spara tid kan du dra och uppdatera allt på en gång med -u flagga:
hg pull -u
NOTERA: Mercurial kommer att uppmana dig när en binär fil uppdateras eller slås samman. Om du inte är säker på att du har gjort ändringar i lokala binära filer, välj alltid "(O) andra" alternativ istället för "(Lokal" alternativ.
Det finns flera krångliga aspekter att utfärda samma kommandon om och om igen, till exempel att komma ihåg att ange ett användarnamn när man begår, måste skriva in ett lösenord varje gång du trycker på etc. Många av dessa inställningar kan lagras i det så kallade en hgrc fil. För att skapa en hgrc fil, använd din favorit textredigerare och ange följande:
[sökvägar] default = https://bitbucket.org/username/reponame
Detta berättar Mercurial vilken väg att använda som standard för push och pull kommandon. Var noga med att ersätta den här falska adressen med den riktiga adressen till ditt fjärrförråd. Ange sedan följande:
[ui] användarnamn = Förnamn Efternamn
Detta berättar Mercurial vilket användarnamn som ska användas som standard när man begår. Ännu en gång, ersätt det med dina korrekta uppgifter och var noga med att e-postadressen matchar den du anmälde dig till. Slutligen ange:
[auth] host.prefix = bitbucket.org host.username = användarnamn host.password = lösenord host.schemes = http https
Detta berättar Mercurial vilka referenser som ska användas när du trycker på ett säkert fjärrförråd så att du inte behöver ange ett användarnamn och lösenord varje gång du trycker på eller drar. Var noga med att ersätta prefixet med den kortaste möjliga delen av din värds adress och inte inkludera http: // protokoll i prefixet heller. Därefter ersätt användarnamnet och lösenordet med den du registrerade dig hos din värd med. Schemat berätta Mercurial vilka protokoll som försöker ansluta till.
Slutligen spara filen som hgrc (utan punkt eller förlängning i slutet) inuti de .hg mapp i ditt förråd. Du behöver inte längre manuellt ge användarnamn, lösenord eller banor när du utfärdar kommandon från och med nu.
Versionskontroll kan tyckas lite skrämmande för de oinitierade, men ansträngningen är värt. Det ger dig lugn och ro för att veta att du på något sätt kan rulla ett brutet projekt tillbaka till en punkt där den fungerade tidigare. På samma sätt innebär användningen av fjärrförråd att koden inte bara kan delas med lagmedlemmar, men att återställa projektet efter att något katastrofalt inträffat (som en hårddiskfel) är lätt.
För att lära mig mer om distribuerad versionskontroll och Mercurial rekommenderar jag starkt att besöka Hg Init. Den har en serie artiklar som förklarar versionskontrollpraxis och Mercurial-funktioner i djupet. Det är kortfattat, mycket informativt, lätt att läsa, lätt att förstå och till och med lite roligt.
Accentsconagua