Arbeta enligt flöden med versionshantering

När vi jobbar med versionshantering finns det många anledningar till varför det är viktigt att arbeta enligt en standard. För det första ger det alla en gemensam grund att följa, vilket underlättar kommunikation och samarbete. Det ökar även effektiviteten och minskar risken för misstag eftersom alla vet vad som förväntas av dem.

För det andra ger det en känsla av trygghet för alla parter eftersom det finns en tydlig bild av vad som är acceptabelt och vad som inte är det. Detta minskar risken för konflikter och gör det lättare att hantera potentiella problem.

För det tredje tillåter det jämförelse och utvärdering av olika resultat eftersom alla följer samma riktlinjer. Detta gör det enkelt att se vilka metoder som är mest effektiva och möjliggör förbättring och utveckling.

Generellt sett är det viktigt att arbeta efter en standard eftersom det ökar effektiviteten, minskar risken för fel och inkonsekvenser samt gör det möjligt att jämföra och utvärdera resultat. Det är därför viktigt att välja rätt standard och följa den så att allt går så smidigt och effektivt som möjligt.

Kom överens om ett arbetsflöde

Git är väldigt flexibelt och låter dig skapa ditt eget arbetsflöde eller adaptera till ett redan existerande. De mest populära flödena är: Basic, Feature Branch, Gitflow, och Forking. Låt oss utforska dessa nedan!

Basic

Med detta arbetsflöde har vi ett centralt förvar. Det innebär att alla som jobbar med förvaret klonar det, arbetar på koden lokalt, commitar sina förändringar och slutligen pushar till det centrala förvaret.

Det är väldigt bra om du ska bygga någonting simpelt. Så fort vi får minsta lilla komplexitet; som att två utvecklare jobbar med olika funktionaliteter samtidigt i ett projekt, är detta flöde bristfälligt. Anledningen är att båda jobbar på samma branch, vilket skapar problem för den utvecklare som pushar sin förändring sist.

Side note: Problemet jag beskriver ovan går självklart att lösa enkelt med “git pull” lokalt och åtgärda sammanslagningskonflikterna innan nästa push.

Feature Branch

Detta arbetsflöde beskriver sig själv relativt bra. Vi har fortsatt ett centralt förvar med en master branch. Däremot commitar vi inte förändringar direkt mot denna, utan varje förändring sker i en separat branch (därav namnet).

Med detta flöde kan vi enkelt verifiera nya funktioner innan dessa slås samman med master branchen. Dessutom får vi en tydlig separation på att master är allt som är redo för produktion och är stabilt.

Fördelar:

• CI/CD vänligt
• Ett simpelt men ändå tydligt flöde
• Idealt om vi endast har en version av kod i produktion

Nackdelar:

• Det är väldigt lätt att buggar hamnar i master branchen, vilket orsakar instabila versioner
• inte rekommenderat när vi behöver flera versioner av vår kod i produktion

Gitflow

Gitflow är väldigt likt Feature Branch. Skillnaden är att vi nu har en branch till förproduktionskod, denna befinner sig mellan funktionsbrancherna och master branchen för att eliminera buggig kod från master. Det ger oss ett tillfälle att först verifiera en ny funktion innan denna slås samman med förproduktionsbranchen. När vi har slagit samman funktionen kan vi därefter testa koden och säkerställa att den är buggfri innan vi gör en ytterligare sammanslagning med master branchen.

Fördelar:

• Funkar bra om vi behöver flera versioner av vår kod i produktion
• Risk för att färre buggar når vår master produktion
• Fungerar bra om vi har en traditionell modell för släpp av kod, det vill säga att vi har versioner som släpps med mellanrum om veckor eller månader

Nackdelar:

• Det tar längre tid för nya funktioner att nå master produktionen
• Stora förändringar kan ta längre tid att reda ut konflikter för
• Baserat på sammanslagningar framför rebase av commits, vilket frångår den linjära historiken som är att föredra när vi arbetar med Git

Forking

Forking innebär att varje utvecklare skapar sina egna kopior (“forks”) på ursprungsförvaret. Med detta får vi ett decentraliserat arbetssätt där en kan jobba på projektet utan att störas av andra utvecklares förändringar. Det kan till exempel vara väldigt effektivt om du vill vidareutveckla ett open source projekt.

Hur kan arbetsflödet med forking se ut för att bidra till ett open source projekt?

1. Du forkar ursprungsförvaret till ditt eget konto på till exempel GitHub
2. Du klonar ner en version av ditt forkade förvar till din egen maskin
3. Du utför förändringar i ditt lokala förvar, commitar dessa och pushar sedan din förändring till ditt forkade förvar
4. Du skapar en “pull” förfrågan från ditt forkade förvar till ursprungsförvaret med din föreslagna förändring
5. Den som underhåller ursprungsförvaret (“the maintainer”) går igenom din förfrågan och avgör om förändringen ska slås samman eller inte

Fördelar:

• Enkelt att bidra till open source projekt
• Oberoende av förändringar i ursprungsförvaret
• Lätt att integrera egna förändringar
• Möjligheten att testa förändringar innan en “pull” förfrågan skapas

Nackdelar:

• Fler bollar i luften, vilket lätt kan skapa förvirring
• Kan leda till konflikter när ursprungsförvaret uppdateras
• Kräver att man är extra uppmärksam på ursprungsförvaret

Summering

Det finns många möjligheter när vi arbetar med Git, ett arbetssätt passar inte alla och det är därför viktigt att utvärdera vilket syfte som passar ditt projekt bäst. Ibland behöver vi till och med skräddarsy en egen standard.

Behöver du experthjälp eller är intresserad av att lära dig mer om versionshantering, CI/CD eller andra moderna arbetssätt inom IT-världen? Klicka här för att kontaka oss!

Rasmus Karlsson

Consultant

Follow

• Email
• LinkedIn

• 2025 2
• 2024 2
• 2023 11
• 2022 6
• 2021 3