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
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.
Git innebär några extra steg: Vi måste t.ex. uppenbarligen göra både en
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
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:
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
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
Skicka en kommentar
Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.