Versionshantering- Git

mars 5, 2013

För oss på Edument har Git blivit något av en standard för hur effektiv versionshantering ska gå till. Beskedet från Microsoft om Git-integration i Visual Studio 2012 kom som en relativt oväntad, men för oss väldigt spännande nyhet. Vi har arbetat med Git länge och håller kurser på olika nivåer inom ämnet. Intresset inom organisationen är så pass stort att vi genast började skapa en kurs anpassad för just Visual Studio 2012, där vi tar en titt på de nya verktygen samtidigt som vi går igenom Git från början.

I det här inlägget ska jag försöka att ge en kort överblick över innehållet i kursen och belysa varför vi finner Git intressant till den graden som vi gör.

Här kan du se Informators utbildningar inom Git

Versionshantering – En kort historik

Historiken kring versionshanteringssystem är både lång och brokig. Versionshantering hjälper oss som bekant att hålla reda på ändringshistorik för våra filer. För programmerare handlar det oftast – men inte uteslutande – om kod.

Mängden versionshanteringssystem som existerat har tagit oss från helt lokala system i stil med RCS där alla operationer skedde lokalt, till CVS och senare Subversion (SVN) där vi istället har haft klient/server-beteende och sparat all historik centralt. Därefter har även så kallade distribuerade versionshanteringssystem i stil med Git, Bazaar och Mercurial dykt upp.

Även om majoriteten av de distribuerade systemen funnits sedan 2005 så är troligtvis idén kring en centraliserad repository den som är mest spridd och som de flesta känner sig bekväma med. Medan exempelvis SVN är ett verktyg som är enkelt att använda, så för det med sig en mängd inneboende problem. Större delen av problematiken kretsar kring att vi hela tiden måste ha tillgång till den centrala servern, oavsett om vi vill göra en commit, skapa en diff mellan två filer eller skapa en branch eller en tag.

Icke-centraliserade system som exempelvis RCS hade en bra idé som innebar att all historik sparades lokalt, men tillät istället inte någon central punkt för ändringshistoriken alls. Det resulterade istället i att samarbetet på samma kodbas blev svårt.

Ett system såsom Git tillåter istället att vi skapar våra repositories lokalt, men att vi även kan klona en repository komplett med all historik från ett system till ett annat. Med andra ord: All versionshistorik finns på din lokala dator, men du har även möjlighet att dela med dig av den. Så även om vi kan prata om ”centrala” punkter såsom GitHub eller BitBucket, så är dessa system inte överordnade på något sätt. De innehåller helt enkelt en kopia av det du redan har lokalt.

Fördelarna med decentralisering

Många förknippar Git med att arbeta via ett konsolfönster eller en bash-terminal. Exempelvis så skapar git init en ny, tom repository. Git använder en ”staging area” för att veta vad som ska ingå i nästa commit och git add <filnamn> lägger till en fil i arean. Slutligen låter git commit oss skriva historiken till vår lokala repository. För att synkronisera sin repository med en annan kan vi använda git pull för att hämta ändringsinformation, alternativt git push för att skicka våra egna ändringar till en avlägsen repository. En commit i Git är alltså inte helt synonym med en commit i exempelvis SVN.

Git innebär några extra steg: Vi måste t.ex. uppenbarligen göra både en commit OCH en push. Det innebär i regel en inlärningskurva som gör det svårare att komma igång med jämfört med de centraliserade motsvarigheterna. Den som investerat tiden som krävs upptäcker däremot ofta fördelarna med ett decentraliserat versionshanteringssystem. Jag kan exempelvis skapa en lokal branch att arbeta i och använda git merge för att slå ihop med min master-branch när jag är klar. Alternativt hade jag kunnat använda git rebase för att se till att min branch aldrig ens förekommer i min historik. Eftersom att allting sker lokalt, så är det enbart jag som arbetar i min branch, och med rebase är den enbart synlig för mig. Först när jag är redo att dela med mig så körs git push. Vi har alltså ett otroligt kraftfullt och flexibelt verktyg, men som även kan vara höljt i mystik för en användare.

Visual Studio och Git

Nyligen skedde däremot en intressant utveckling från Microsofts sida – Stöd för Git i Visual Studio 2012! I och med Microsofts Update 2 till Visual Studio 2012 (även kallat Visual Studio 2012.2) så kommer verktyg för Git i form av en extension till nuvarande Team Explorer att släppas. Update 2 är för nuvarande på CTP-stadie (Community Technology Preview).

Verktyget möjliggör att vi till stor del kan arbeta med Git utan att lämna Visual Studio. Det innebär däremot inte att vi nödvändigtvis måste överge konsolen/terminalen om vi inte vill. Vi kan exempelvis använda Visual Studio som en visuell indikator för vår lokala repository och fortsätta att sköta operationerna ifrån en konsol om vi så önskar.

Traditionellt har Team Explorer inneburit att använda versionshanteringen som finns tillgänglig via Team Foundation Server (TFS). TFS använder sig av en centraliserad variant som bland annat kräver konstant uppkoppling mot servern när vi arbetar. Numera kan vi däremot arbeta med helt lokala Git-repositories inifrån Visual Studio, men även göra push/pull mot en repository på exempelvis GitHub. Även Microsoft har satt upp möjligheten att använda TFS som central punkt att pusha mot – Här får vi numera möjlighet att välja mellan antingen Team Foundation Version Control eller Git. Men, en av de stora nyheterna här är fortfarande att vi inte måste använda TFS.

Git är ett system som är exceptionellt duktigt på att göra merges. Om ändringar från två olika versioner av samma fil behöver slås samman så kommer det större delen av tiden att gå smärtfritt. Vid de tillfällen Git inte klarar av att göra detta kommer vi bli tvungna att manuellt berätta hur vår merge ska ske. En fördel med att arbeta inifrån Visual Studio är att vi kan se vår diff direkt, utan att behöva lämna vårt IDE:

Eftersom Update 2 befinner sig i CTP (version 4 i skrivandets stund) så kommer troligtvis mer att hända innan den slutliga releasen. Nyheten är dock så intressant att vi inte kan bärga oss, utan följer utvecklingen och ger kurser i ämnet redan nu. Vi tar upp Git ur ett perspektiv för helt nya användare och undersöker skillnader mellan centraliserade/distribuerade system i större detalj. Vi tittar på konceptet kring hur Git använder en riktad acyklisk graf (DAG) för att enbart spara ändringar och vad detta får för konsekvenser ur lagringsperspektiv, samt hur arbetsflödet förenklas när flera utvecklare samarbetar.
Visual Studio 2012 är givetvis ett stort inslag, men vi kommer även att titta på hur vi kan gå utanför VS2012 för att kombinera konsolen och vårt IDE. Kursen håller samma höga kvalitet som blivit synonymt med övriga Edument-kurser och vi ser att intresset för distribuerad versionshantering är på uppgång.

/Eric Lavesson, Edument