Vad är versionshantering?
Versionshantering är systemet som sparar varje ändring i ett projekts kod med vem som gjorde den, när och varför. Det gör att man kan gå tillbaka till ett tidigare läge och att många kan arbeta parallellt utan att skriva över varandra. Git är dagens standard, med tjänster som GitHub och GitLab byggda ovanpå.
Versionshantering är en av de mest grundläggande sakerna i modern mjukvaruutveckling, men också en av dem som sällan förklaras för den som beställer. Det är värt att förstå, för det hänger direkt ihop med en av de viktigaste frågorna av alla: äger ni verkligen er kod? Här är vad det betyder.
Definitionen
Versionshantering är systemet som sparar varje ändring i ett projekts kod, med information om vem som gjorde den, när och varför. I stället för att koden bara finns i ett enda ständigt föränderligt skick byggs en fullständig historik upp, där varje steg är bevarat och går att återvända till.
Det löser två problem på en gång. Dels kan man alltid backa till ett tidigare läge om något går fel – en oändligt mycket kraftfullare ångra-funktion. Dels kan många utvecklare arbeta i samma kodbas parallellt utan att skriva över varandras arbete, eftersom systemet håller reda på och väver ihop ändringarna.
Git är standarden
I praktiken betyder versionshantering i dag nästan alltid Git. Det är verktyget som sköter själva historiken, och det har blivit så dominerande att det är den självklara standarden i så gott som varje professionellt utvecklingsteam.
Ovanpå Git ligger tjänster som GitHub och GitLab. De lagrar koden centralt på en säker plats och lägger till allt som gör lagarbete smidigt: kodgranskning, behörighetsstyrning, ärendehantering och automatiska tester. Git är motorn under huven; GitHub och GitLab är plattformarna där teamet samlas kring koden. Skillnaden är värd att känna till, för det är på plattformen din åtkomst som beställare bor.
Två begrepp: commit och branch
Två ord återkommer ständigt, och de är enklare än de låter.
En commit är en sparad ändring. Varje gång en utvecklare avslutat ett moment sparas resultatet som en commit – en namngiven punkt i historiken med en kort beskrivning av vad som gjordes. Det är som att sätta ett bokmärke efter varje avklarat steg, så att man alltid kan hitta tillbaka.
En branch, på svenska gren, är en parallell arbetskopia av koden. Där kan en utvecklare bygga något nytt eller prova en idé utan att röra den fungerande koden som redan är i drift. När arbetet är klart och testat vävs grenen ihop med huvudspåret. Grenar är det som gör att flera personer kan bygga olika saker samtidigt utan att stå i vägen för varandra.
Beställarvinkeln: kräv åtkomst till repot
Här blir det affärskritiskt. All kod i ett projekt bör ligga i ett versionshanterat repository – ett repo – och det avgörande är vem som har åtkomst till det.
Ligger koden i ett repo som ni som beställare äger och har full åtkomst till, har ni kontroll. Ni kan när som helst granska vad som byggts, ta in en annan leverantör som fortsätter där den förra slutade, och vara trygga i att hela historiken finns kvar. Ligger koden däremot bara hos leverantören, sitter ni fast: ni är beroende av deras välvilja för att komma åt ert eget system, och en avslutad relation kan bli mycket dyr.
Kravet är enkelt att ställa och bör ställas tidigt: all kod ska ligga i ett versionshanterat repo som er organisation äger eller har administratörsåtkomst till. Det är en av de billigaste försäkringarna mot leverantörsinlåsning som finns. Vi på Weapp ser det som en självklarhet att beställaren äger sin kod – det är trots allt ni som betalat för den.
Så använder du det här
Du behöver inte kunna Git för att ställa rätt krav. Fråga var koden lagras, om den är versionshanterad, och se till att ni står som ägare eller administratör på plattformen – inte bara som inbjuden gäst. Då har ni både historiken och kontrollen över ert system, oavsett hur samarbetet utvecklas. Vill ni ha hjälp att reda ut hur er kod hanteras i dag, hör av er.
Vanliga frågor
Vad är versionshantering, enkelt förklarat?
Det är en detaljerad ändringshistorik för kod. Varje gång en utvecklare gör en ändring sparas den som en punkt i historiken, med vem, när och varför. Man kan när som helst gå tillbaka till ett tidigare läge, jämföra versioner och se exakt vad som förändrats. Tänk ångra-funktionen i ett dokument, fast mycket mer kraftfull och gjord för lagarbete.
Vad är skillnaden mellan Git, GitHub och GitLab?
Git är själva verktyget som sköter versionshanteringen och körs där koden byggs. GitHub och GitLab är webbtjänster ovanpå Git som lagrar koden centralt och lägger till samarbete: granskning, behörigheter, ärenden och automatik. Git är motorn, GitHub och GitLab är plattformarna där team samlas kring koden. Man kan använda Git utan dem, men sällan tvärtom.
Vad betyder commit och branch?
En commit är en sparad ändring – en namngiven punkt i historiken som säger vad som ändrades och varför, ungefär som att sätta ett bokmärke efter varje avslutat arbetsmoment. En branch, eller gren, är en parallell arbetskopia där man kan bygga något nytt utan att röra den fungerande koden, och sedan väva ihop det med huvudspåret när det är klart och testat.
Varför är versionshantering viktigt för mig som beställare?
Det avgör om ni faktiskt äger och kontrollerar er kod. Ligger koden i ett versionshanterat repo som ni har åtkomst till kan ni när som helst byta leverantör, granska vad som byggts och vara säkra på att inget går förlorat. Utan det sitter hela historiken hos leverantören, och ni är beroende av deras goodwill för att komma åt ert eget system.
Vad ska jag konkret kräva av min leverantör?
Kräv att all kod ligger i ett versionshanterat repository som ni har åtkomst till, helst ägt av er organisation. Be om att stå som ägare eller administratör på GitHub eller GitLab, inte bara som inbjuden gäst. Då har ni kontroll över koden oavsett vad som händer med samarbetet, och slipper vara utlämnade om en relation tar slut.