"Jag är säker på att Git är bra, men det ser ut komplicerat - jag kommer att hålla fast vid mitt nuvarande arbetsflöde" är som att säga "Jag är säker på att IDEs som FlashDevelop och Sublime Text är bra, men de ser komplicerade ut - jag håller fast med Anteckningar". Ja, det är lite av en inlärningskurva, och du kan leva utan det, men det är dumt att. I den här artikeln ska jag förklara varför Git (och GitHub) är så bra och visa dig hur du snabbt och enkelt kan komma igång.
Notera: Många av vad jag säger här gäller för andra versionsstyrningssystem, som Subversion, men Git är så populärt att om du har ett fritt val, rekommenderar jag att det är vad du går med.
Git har fördelar för alla spelutvecklare, oavsett om de arbetar solo eller i ett lag. Låt oss gå igenom de stora:
Förmodligen huvudpunkten för Git är att det kan ta en "ögonblicksbild" av hela spelets arbetsmapp när du frågar, och du kan när som helst återgå till någon av dessa snapshots när som helst.
Detta är ett mycket bättre system än att göra en kopia av hela din mapp när du får en fungerande version av spelet, eller maila koden till dig själv med en beskrivning så att du inte förlorar det.
Dessutom är du inte begränsad till en rak linje med undos och redos; du kan dela upp ditt projekt i en separat gren av ögonblicksbilder och byta mellan grenarna efter vilja. Det betyder att du kan lägga till nya funktioner i version 1.1, sedan växla tillbaka till v1.0 och tillämpa en buggfix; eller arbeta på en experimentell funktion och skrapa den om den inte fungerar. eller behåll dina mobil- och tablettversioner separerade men ändå tillsammans.
Faktiskt gör Git inte bara låta du lägger till kommentarer - det uppmuntrar dig att även kräva dig. I grund och botten, när du sparar en ögonblicksbild skriver du en kommentar som beskriver de förändringar du gjort sedan senaste ögonblicksbilden.
Här är några exempel kommentarer från Tiled, en stor nivåredaktör som vi har tagit fram tidigare:
Förutom att det blir lättare att hitta en viss punkt i ett projekts historia (vilket ofta är användbart för att spåra orsaken till en bugg), bidrar det också till att bygga bra utvecklingsvanor: du kommer att hitta dig själv att bryta arbetet ner i mindre uppgifter så att varje del kan beskrivas fullständigt i en kort kommentar snarare än att arbeta på åtta olika saker på en gång.
Hittills har jag pratat om Git, vilket bara är ett verktyg som Zip eller email eller FTP. GitNav, däremot är en webbplats som kan vara värd för dina Git-snapshots (och därmed hela ditt projekt).
Det finns andra Git-webbhotell, och det är också möjligt att vara värd för dina Git-projekt själv på din egen server, men GitHub är överlägset mest framträdande. Tänk på det som Gmail: det är inte den enda webbaserade e-postappen, men för många kan det också vara.
Många spel- och gamedevverktyg är offentligt tillgängliga på GitHub, till exempel Tiled (som jag nämnde ovan) och Starling Framework (som vi också behandlade tidigare). Det betyder att istället för att bara hämta den nuvarande versionen av Starling Framework som en zip-fil och extrahera den till ditt projekt kan du importera hela mappen till ditt projekt och hålla det automatiskt uppdaterat när det ändras.
Du kan också föreslå nya funktioner eller rapportera fel via frågespåraren:
Du kan till och med skapa en lokal kopia (en "gaffel") av projektet, lägga till den nya funktionen eller fixa felet själv och skicka bilden till projektets ägare för att överväga att slå samman med huvudversionen.
(Du kanske har märkt att vi har börjat ta emot fler av våra källfiler på GitHub över Tuts + - det här är i stort sett varför!)
Alla orsakerna ovan gör Git väldigt värdefullt för solo-utvecklare. Men många av dessa fördelar är i sig också praktiska när man arbetar i ett lag:
Git har också funktioner för att "sammanfoga" olika bitar av kod tillsammans och tvinga dig att hantera eventuella konflikter istället för att bara blint skriva över delar av projektet.
Installera Git och ställa in det brukade vara en besviken affär med att använda kommandoraden för att generera "SSH-nycklar" och usch. Men nu är det väldigt enkelt: allt du behöver göra är att ladda ner och installera GitHub för Windows eller GitHub för Mac, beroende på vad som passar.
Ja, ja, jag vet, jag sa GitHub är en webbplats för värd för Git-snapshots, men här säger jag att du installerar GitHub för att använda Git. Det är förvirrande: GitHub-the-app är programvara som installerar Git och ger dig ett trevligt gränssnitt för det, samtidigt som du får möjlighet att vara värd för dina ögonblicksbilder på GitHub-webbplatsen.
Oroa dig inte om det. Bara ladda ner versionen för ditt operativsystem och installera det. Er, om du inte använder Linux, då är jag rädd för dig do måste gå på den tvungna vägen.
Jag går igenom dig genom att konfigurera Git för vilket spel eller projekt du arbetar för, så du kan börja använda den för riktigt, snarare än som en falsk övning. Jag använder GitHub för Windows, men stegen kommer att vara väldigt lika i GitHub för Mac. Jag låtsas också att bfxr är mitt projekt jag jobbar med, vilket det inte är helt.
Öppna GitHub för Windows och klicka skapa för att börja göra en ny "repo" (kort för "förvar" - i grunden den plats där alla dina ögonblicksbilder för detta spel eller projekt sparas). Ange ett namn och en beskrivning för ditt projekt och lämna katalogen som standard (du behöver inte göra matchningen till ditt projekt befintliga katalog). Se till Tryck till github är inte markerad.
Dubbelklicka på din nyskapade repo för att öppna den i appen:
Du får se att det berättar att det finns två filer att vara "engagerade" (det vill säga att läggas till repo som en stillbild). Det här är vanliga Git installationsfiler, så skriv en blid kommentar i Budskapande meddelande ruta och träffa Begå:
Klicka nu verktyg> öppna i explorer för att öppna Gits arbetsdokument för projektet. Det kommer att vara tomt bortsett från de två installationsfilerna (och en dold .git mapp som du kanske eller inte kan se):
Kopiera hela projektet till den här mappen. (Ja, det här är rörigt, men åtminstone så kan du vara säker på att du har en säkerhetskopia om något går fel.)
Gå tillbaka till GitHub för Windows - det kommer att märka att dessa nya filer bara har dykt upp:
Överför dessa filer också, och du är helt upptagen med din grundläggande första repo!
Gör nu en förändring av ditt projekt. Du kan lägga till en ny fil eller ändra en befintlig:
Gå tillbaka till GitHub för Windows, och det kommer också att upptäcka det här. Förbind denna ändring, välj sedan den från osynkroniserade förpliktelser lista och träffa återgå commit. Du har nu ett nytt åtagande som återgår till föregående åtagande - det verkar lite förvirrande, men det betyder att du håller reda på allt du gör!
Kontrollera dina faktiska projektfiler:
Din nya fil (eller ändringen du gjorde till den andra filen) är verkligen borta. Du kan återgå tillbaka, om du vill, lägga till ytterligare ett åtagande till din lista, eller rulla tillbaka förbinder sig att helt ta bort den från listan.
Det är allt? Japp. Men också, nej. Jag har lagt hela artikeln på GitHub så att du kan experimentera med webbplatsen genom att begära "förbättringar" (förslag på vad du vill se tillagd) och logga "buggar" (problem med artikeln).
Om du känner dig riktigt äventyrlig, kan du försöka "forking" artikeln till din dator, göra tilläggen själv och sedan skicka in en begäran om att få den tillagd på webbplatsen ... om inget av det var förnuftigt för dig, oroa dig inte ; en senare revision kommer att innehålla mer information!