{ FJS26 }

Branches och
pull requests

Så jobbar ni i samma repo utan att gå i vägen för varandra

[ v40 · torsdag 1 oktober 2026 ]

ÖVERSIKT

Innehåll

Varför branches

Problemet de löser.

01 · PROBLEMET

Sex grupper, ett repo

Tänk er att alla jobbar direkt på samma gren.

• Ni skriver över varandras kod utan att märka det.
• Halvfärdig kod ligger blandad med färdig.
• Går något sönder vet ingen vems ändring det var.
• Ingen hinner titta på koden innan den är inne.

Branch

En egen linje av arbete. Ni utgår från samma kod, men era ändringar syns bara hos er tills ni väljer att visa dem.

• Att skapa en branch kostar ingenting och tar inget utrymme.
• Ni kan ha hur många som helst.

Branchen är billig. Att förstöra för fem andra grupper är dyrt.

Branchen i praktiken

Kommandona ni faktiskt skriver idag.

02 · REPOT

Tre sorters branch idag

Så här ser workshoprepot ut.

02 · KOMMANDON

Kom igång

• git clone <url> — hämta hem repot. Ni landar på main.
• git switch dev — byt till den tidigare utvecklarens gren.
• git switch -c fix/grupp-3 — skapa er egen utifrån dev och byt till den.
• git push -u origin fix/grupp-3 — lägg upp den på GitHub.

switch eller checkout?

Båda byter branch. switch är nyare och gör bara en sak, checkout gör två helt olika saker.

• git checkout byter gren OCH återställer filer — därför kan git checkout -- fil kasta ditt arbete.
• git switch byter gren. git restore återställer filer.
• Allt ni googlar kommer att säga checkout. Det är samma sak.

02 · COMMITS

Committa per ticket

Skriv ticket-id först. Det gör granskningen mycket lättare.

• git commit -m "A11Y-1: kopplar label till varje fält"
• En commit per ticket, inte allt på slutet.
• Granskaren kan följa ert resonemang i historiken.
• Skriv vad och varför, aldrig bara "fix".

Pull requests

Att be om att få lägga in sitt arbete.

Pull request

En begäran om att få lägga in er branch i en annan. Den öppnar samtidigt ett samtal om koden.

• PR:en är en diskussion, inte en leverans.
• Idag mergar vi ingen. Poängen är granskningen.

03 · PR

Två grenar, inte en

Varje PR har en bas och en jämförelse. Blandar ni ihop dem pekar den fel.

• base — dit ni vill lägga in koden. Hos oss: dev.
• compare — er egen branch, fix/grupp-N.
• GitHub föreslår main som base. Byt den till dev.
• Fyll i PR-mallen. Kryssa bara i det ni faktiskt gjort.

En ärlig PR är lättare att granska än en komplett.

03 · FÄLLOR

Tre vanliga misstag

• Branchen utgår från main i stället för dev. Då saknas Kims kod och diffen blir hela projektet.
• Länken går till /pull/new/. Det är formuläret, inte PR:en. PR:en har ett nummer: /pull/3.
• Allt i en commit på slutet. Granskaren ser en vägg och kan inte följa vad ni tänkte.

Granska någon annans kod

Den del ni lär er mest av.

04 · GRANSKNING

Ni granskar i en ring

Grupp 1 granskar grupp 2, grupp 2 granskar grupp 3, sista granskar grupp 1.

• Ni granskar aldrig er egen kod.
• Er kod granskas av någon som inte satt med när den skrevs.
• Det är därför granskning fungerar.

Ni får inte granska genom att bara läsa diffen. Ni ska köra koden.

04 · SÅ GÖR NI

Fyra steg

• git fetch origin och git switch fix/grupp-N — hämta hem deras branch.
• Kör de fem testerna: tangentbord, 320 px, 200 % text, uppåt, Lighthouse.
• Kommentera på raden i Files changed. Minst tre kommentarer.
• Avsluta med Request changes eller Approve — och motivera.

04 · KVALITET

Två sorters kommentar

04 · ATT FÅ KRITIK

När ni får kommentarer

• Svara på varje kommentar.
• Håller ni inte med, säg det och motivera. Granskaren kan ha fel.
• Rätta, committa på samma branch, pusha. PR:en uppdateras av sig själv.
• En PR är en diskussion, inte en dom.

FUSKLAPP

Allt ni behöver idag

• git switch dev
• git switch -c fix/grupp-N
• git commit -m "A11Y-1: ..."
• git push -u origin fix/grupp-N
• git fetch origin · git switch fix/grupp-N

Nu kör vi

< Skapa er branch >

Klona repot, byt till dev, skapa fix/grupp-N och pusha den. Säg till när alla grupper har en branch uppe, så tar vi ringen.