Share
Denne artikkelen er ment å være en endelig veiledning for hvordan du skal riktig versjon kontrollere dine Unity-prosjekter!
Versjonskontroll er et av de viktigste verktøyene i noen utviklers arsenal. Det gjør at du enkelt kan rulle tilbake endringer hvis du ved et uhell bryter noe, sammenligner eldre og nyere versjoner av koden din for å se hva som er annerledes, og det tillater lag å jobbe med samme kode uten at du ved et uhell overskriver hverandres arbeid. Inntil nylig var bare Unity Pro-prosjekter i stand til å være riktig versjonskontrollert. Men siden Unity 3.5, er det nå mulig å versjonskontrollprosjekter i den gratis versjonen av Unity også.
Et versjonskontrollsystem, eller VCS, holder oversikt over endringer du har gjort i filer i mappen, også kjent som din "arbeidskopi". Disse endringene lagres ved siden av mappen i en database kjent som et "lager". Hver gang du endrer noe i arbeidskopien, må du forplikte de endringene til depotet. VCS sammenligner deretter det som allerede er i lageret til de innkommende endringene og lagrer kun forskjellene. Dette holder depotet så lite som mulig.
For dette prosjektet bruker vi Mercurial som er en distribuert VCS. I motsetning til sentraliserte VCS-systemer som Subversion (SVN), som vanligvis stole på et eksternt lager lagret på en server, kan en distribuert VCS være vert for lokale databaser, noen ganger kalt "lokale grener", direkte på datamaskinen. Dette betyr at du kan gjøre endringer, forplikte dem til den lokale grenen din, teste dem og til og med kaste dem hvis noe bryter, alt uten å måtte underordne gruppemedlemmene dine til endringene dine til du vet at de er perfekte. Når du er sikker, kan du "skyve" de endringene til et eksternt lager for at teamet ditt kan "trekke" inn i sine egne lokale grener.
Et Unity-prosjekt krever viss metainformasjon for å huske hvilke komponenter og forbindelser som er satt på de ulike eiendelene. Tradisjonelt ble denne meta-informasjonen lagret som et sett med binære filer i bibliotek-mappen til et Unity-prosjekt. Denne "binære blob" kan imidlertid ikke fusjoneres riktig, slik at endringer som gjøres av to personer, kan stompe over hverandre, noe som forårsaker ting å bryte i redaktøren, selv om de redigerer ulike eiendeler.
Løsningen på dette er å slå på Meta Files i prosjektinnstillingene.
Dette vil føre til at Unity oppretter metafiler ved siden av hvert aktivum i prosjektmappen Assets. Nå, når en ressurs er endret i editoren, vil bare aktiva og den tilhørende metafilen rapportere endringer, i stedet for hele bibliotekmappen.
Både Windows og OSX har Mercurial installatører. Besøk Mercurial nettside og klikk på den store nedlastningsknappen. Nettstedet vil automatisk gjenkjenne hvilket operativsystem du bruker og laste ned det riktige installasjonsprogrammet.
Unzip installasjonsprogrammet og kjør det. Klikk gjennom alle trinnene, og det skal installeres uten at det trengs noe intervensjon.
For å sikre at Mercurial installeres riktig, åpne en kommandolinje. På Windows, trykk Start og skriv inn cmd inn i søkeboksen. På OSX, åpne Spotlight og søk etter terminal.
På kommandolinjen, skriv inn:
hg .
En kort liste med informasjon skal vises, inkludert hvilken versjon av Mercurial du bruker, samt en liste over vanlige kommandoer. For å få fullstendig liste over kommandoer, skriv inn:
hg hjelp
Og for å få hjelp til en bestemt kommando, skriv inn navnet på kommandoen etter hjelp:
Hg hjelper klonen
MERK: Merkurkommandoer begynner alltid med hg, elementet for kvikksølv på det periodiske bordet. Heldigvis ble denne smarte navngivningen brukt fordi det er lett å skrive.
Det første vi må gjøre er å gi vår prosjektmappe et lager.
På kommandolinjen skriver du inn:
hg init
Det er det. Vår mappe har nå et lager og er klar for versjonskontroll. Hvis du har skjulte filer slått på, vil du legge merke til a .hg mappen er opprettet i prosjektmappen. Dette er hvor depotet ligger. Hvis du av en eller annen grunn vil fjerne fjernkontroll, sletter du bare .hg mappe. Din arbeidskopi av filene blir ubemerket.
Nå som vår prosjektmappe har et lager, la oss sjekke lagringsplassens status for å se hva som er endret. Mercurial vil akseptere forkortede kommando navn, så noen av følgende vil fungere:
hg status hg stat hg st
En statusrapport skal komme opp med en liste over filer, hver med et enkelt brev ved siden av dem. I dette tilfellet vil alle filene ha spørsmålstegn ved siden av dem. Spørsmålstegnet angir at filen ikke er versjonskontrollert i depotet ennå.
| ? | En fil som er i arbeidskopien, men blir ikke sporet av depotet. |
| ! | En fil som blir sporet av depotet, men mangler i arbeidskopien. |
| EN | En fil som er lagt til i depotet siden siste forpliktelse. |
| M | En fil som har blitt endret siden siste forpliktelse. |
| R | En fil som er slated for fjerning fra depotet på neste forpliktelse. |
Vi må eksplisitt legge til filer i vårt lager for å la Mercurial vite at vi vil at de skal være versjonskontrollert.
Individuelle filer kan legges til:
hg legg til myfile.txt
Hele mappene kan legges til:
hg legg til skript /
La oss legge til hver enkelt uversjonert fil (med en ? spørsmålstegn i statusrapporten) i ett fall ved å ikke spesifisere noe filnavn i det hele tatt:
hg legg til
Utfør en statuskontroll.
hg status
Eventuelle filer som ble lagt til, skulle nå ha et brev EN ved siden av dem, som indikerer at de har blitt lagt til lagringsplassen og nå spores av Mercurial.
Nå som vi har fortalt Mercurial hvilke filer vi vil være versjonskontrollert, må vi forplikte dem til depotet. Hver forpliktelse er som et øyeblikksbilde kjent som en revisjon, som holder styr på forskjellene mellom de forrige revisjonene og den nåværende.
Det er to deler til enhver forpliktelse, en melding og ditt brukernavn. Meldingen er hvor du kommer til å beskrive hva du gjorde, men hold det kort og søtt. Brukernavnet er bare en identifikator for å la noen andre som kan bruke depotet, vite hvem som gjorde visse endringer. Brukernavnet er satt med -u flagg og meldingen er satt med -m flagg:
hg commit -u ian -m "initial"
For å sikre at begåingen var vellykket, må vi sjekke loggen:
hg logg
For å være dobbelt sikker, sjekk statusen for å være sikker på at ingen endringer er igjen.
hg status
En tom statusrapport betyr at alt var riktig forpliktet.
MERK: Det anbefales at du forplikter deg ofte. Hver forpliktelse skal være så "atomisk" som mulig. Det vil si det bør lett beskrives med et enkelt uttrykk som "økt spillerhøyde". Hvis du finner deg selv nødt til å bruke "og" eller komma i dine forpliktede meldinger, så er det nok tid til å lage to separate forpliktelser. Årsaken til dette er å gjøre det enkelt å tilbakestille bestemte endringer du har gjort når du støter på problemer.
Det er to viktige måter å fikse feil på: en tilbakeringing eller en tilbakeringing. En tilbakeringing vil angre den siste kommandoen du skrev inn, som er ideell for å fikse stavefeil i dine forpliktede meldinger eller over nidkjær å legge til.
hg rollback
Utfør en statuskontroll for å sikre at alt ble rullet tilbake på riktig måte.
hg status
En tilbakering er kraftigere, slik at du kan reise tilbake i tid gjennom flere revisjoner, i tilfelle du må sikkerhetskopiere flere endringer du har gjort. For å finne ut hvilken revisjon du vil komme tilbake til, må du først sjekke loggen:
hg logg
Enten kan tallet eller hasen brukes til å referere til en bestemt revisjon mens du går tilbake. Tallet er spesifikt for depotet ditt siden noen andres grener kan ha flere endringer, slik at tallene deres ville være forskjellige. The hash er universell, det betyr at alle kan gå tilbake til en bestemt revisjon på et delt arkiv ved å bruke denne hash-strengen.
For å gå tilbake til en bestemt revisjon, må vi angi revisjonsnummeret ved hjelp av -r flagg. Vi må også fortelle Mercurial å "returnere alle" ved hjelp av -en flagg. Til slutt må vi fortelle Mercurial at vi ikke vil at den skal lage noen backupfiler ved hjelp av --no-backup flagg.
hg tilbake -r 0-a-no-backup
Utfør en statuskontroll for å forsikre deg om at alt er vendt riktig.
hg status
MERK: Hvis du slipper ut --no-backup flagg, vil Mercurial lage backupfiler for alle filer som berøres av tilbakestillingsprosedyren. Disse backupfilene vil alle ha en .orig forlengelse. Pass på at du ikke legger til .orig filer.
Nå som vi har slettet vår feil, la oss sørge for at det ikke skjer igjen. Vi vil permanent ignorere biblioteks- og Temp-mappene slik at det ikke kan tilføyes ved et uhell neste gang vi får utløseren lykkelig med kommandoen legg til.
Mercurial bruker en spesiell fil som heter .hgignore for å lagre navnene på filer og mapper du vil ignorere permanent. Denne filen går rett innenfor prosjektmappen din og er versjonskontrollert akkurat som alt annet. Dette sikrer at alle som bruker repo, ikke kan forurense det med uønskede filer.
Bruk din favoritt tekstredigerer til å skrive inn følgende:
syntaks: glob Bibliotek Temp * .pidb * .sln * .userprefs * .csprog * .orig
Dette forteller Mercurial hva vi vil bruke shell-stil syntaks (kjent som "glob" -syntax) for å ignorere mappene Bibliotek og Temp, ignorere flere midlertidige filer som MonoDevelop lager, og å ignorere .orig filer bare hvis vi ved et uhell lager dem når du går tilbake.
Lagre filen i roten til prosjektmappen din som .hgignore (noter prikken i begynnelsen). Deretter utfører du en annen statuskontroll:
hg status
De .hgignore filen skal nå bli oppført i statusrapporten, men bibliotekmappen, Temp-mappen og andre ignorerte filer skal ikke. Så vi kan trygt bruke add-kommandoen uten å måtte bruke nøyaktige filnavn og deretter legge til resultatene.
hg legg til hg commit -u ian -m "Initial"
Sjekk loggen for å forsikre deg om at begåingen var vellykket.
hg logg
MERK: Mer informasjon om hgignore-filer finner du her.
Hvis du vil dele arkivet med andre utviklere, er det enklest å opprette et eksternt lager på en server og skyve endringene dine til det.
Det første du må gjøre er å finne en Mercurial-vert. Flere finnes, inkludert BitBucket og Kiln; Begge har gratis kontoer for små lag. I vårt tilfelle bruker vi BitBucket, men begge tjenestene fungerer i det vesentlige like. Når du har registrert deg for en konto på begge tjenestene, må du sørge for å opprette et nytt lager ved hjelp av deres webgrensesnitt.
Når du er opprettet, se etter "klonbanen". Det skal se slik ut:
hg klone https://bitbucket.org/username/reponame
Normalt vil denne kommandoen bli brukt til å lage en lokal kopi av depotet. Men vi har allerede et lokalt lager og vi ønsker å sende endringer fra det til fjernlageret i stedet. For å gjøre dette kan vi ta URL-adressen til slutten av klonstrengen og bruke den som mål for push-kommandoen.
hg skyve https://bitbucket.org/username/reponame
Mercurial vil sammenligne det lokale depotet til fjernregisteret for å se hvordan de er forskjellige. Det vil se at vårt lokale lager har nyere endringer som fjernlageret mangler og sender dem til fjernlageret.
Det vil imidlertid først be om et brukernavn og et passord. Disse skal stemme overens med brukernavnet / e-postadressen og passordet du registrerte deg for vertjenesten med.
Mercurial bør rapportere at alle endringer ble vellykket presset, og det betyr at alle som avhenger av depotet ditt, kan nå "trekke" fra det for å motta endringene dine. Først må de klone depotet for å lage en lokal kopi.
hg klone https://bitbucket.org/username/reponame
Og deretter trekk eventuelle endringer som du eller noen andre gjør som tiden går på:
hg trekke
Du må da gjøre en "oppdatering" for å sikre at arbeidskopien din er oppdatert:
hg oppdatering
Men for å spare tid, kan du trekke og oppdatere alt på en gang med -u flagg:
hg pull -u
MERK: Mercurial vil spørre deg når en binær fil oppdateres eller slås sammen. Med mindre du er sikker på at du har gjort endringer i lokale binære filer, velger du alltid "(O) annen" alternativ i stedet for "(L) ocal" alternativ.
Det er flere kjedelige aspekter for å utstede de samme kommandoene om og om igjen, for eksempel å huske å levere et brukernavn når man plikter, må skrive inn et passord hver gang du trykker osv. Mange av disse innstillingene kan lagres i det som er kjent som en hgrc fil. Å opprette en hgrc fil, bruk din favoritt tekstredigerer og skriv inn følgende:
[stier] standard = https://bitbucket.org/username/reponame
Dette forteller Mercurial hvilken vei å bruke som standard for push og pull kommandoer. Pass på at du erstatter denne falske adressen med den virkelige adressen til fjernregisteret ditt. Deretter skriver du inn følgende:
[ui] brukernavn = Fornavn Etternavn
Dette forteller Mercurial hvilket brukernavn du skal bruke som standard når du begår det. Igjen, erstatt dette med de riktige legitimasjonene dine, og vær sikker på at e-postadressen samsvarer med den du registrerte deg med. Til slutt, skriv inn:
[auth] host.prefix = bitbucket.org host.username = brukernavn host.password = passord host.schemes = http https
Dette forteller Mercurial hvilke legitimasjonsbeskrivelser som skal brukes når du trykker på et sikkert fjernlager, slik at du ikke trenger å skrive inn et brukernavn og passord hver gang du trykker eller trekker. Pass på å erstatte prefikset med kortest mulig del av vertsadressen din og ikke inkludere http: // protokoll i prefiks heller. Deretter skal du erstatte brukernavnet og passordet med den du meldte deg til verten din med. Skjemaet forteller Mercurial hvilke protokoller som skal forsøke å koble til.
Endelig lagre filen som hgrc (uten prikk eller forlengelse på slutten) innsiden de .hg mappe i depotet ditt. Du bør ikke lenger manuelt gi brukernavn, passord eller baner når du utsteder kommandoer fra nå av.
Versjonskontroll kan virke litt skremmende for de uinitierte, men innsatsen er verdt. Det gir deg trygghet for å vite at du når som helst kan rulle et ødelagt prosjekt tilbake til et punkt der det fungerte før. På samme måte betyr bruk av eksterne repositorier at kode ikke bare kan deles med lagmedlemmer, men å gjenopprette prosjektet etter at noe er katastrofalt (som en harddiskfeil) er lett.
For å lære mer om distribuert versjonskontroll og Mercurial, anbefaler jeg på det sterkeste å besøke Hg Init. Den har en serie artikler som forklarer versjonskontrollpraksis og Mercurial-funksjoner i dybden. Det er kort, svært informativ, lett å lese, lett å forstå og til og med litt morsomt.
Accentsconagua