Tydliga Git Commits

I projektet jag sitter så gör vi alltid en kodgransking av det som mergas in, innan vi mergar kod till vår master-branch. Det är mest en sanity check så att inget knasigt kommer in på master. Mestadels går det på rutin och det är inget som tar någon tid i anspråk. Efter några år tillsammans så vet vi i teamet vad som passerar en kodgranskning och vad som studsar tillbaka.

Tydliga Git Commits

Tydliga Git Commits 1949 1016 C.A.G

För ett tag sedan granskade jag ett ärende som var aningen större än vanligt och jag hade svårt att följa med bland alla commits. Ärendet hade ett 10-tal commits där man fram och tillbaka hade ändrat på samma kodrader. Det som rörde till det ännu mer var att det inte gick att följa med i commit-historiken, meddelandena speglade inte alls förändringarna i koden. I ett sådant läge är det lätt att känna lusten att abdikera och helt enkelt bara godkänna förändringarna och hoppas på det bästa. Jag funderade då lite över varför vi egentligen skriver commit-meddelanden och hur vi kan underlätta för den som ska kodgranska.

 

Beskriv förändringar

Visst, det är sant att man kan läsa koden för att se vad som skett, men att kortfattat beskriva vad förändringarna avser kan göra underverk för förståelsen när man granskar någon annans commits. Det brukar dessutom vara ett gott tecken på att man är strukturerad och vet vad man håller på med.

 

Anledningen till att vi skickar med en liten infotext i en commit är kanske olika beroende på vem man frågar, men grundtanken är nog att den texten ska underlätta förståelsen för vad som ändrats i koden. Oavsett var, eller hur infotexten skrivs så finns det en mottagare i andra änden (kanske jag själv) och då bör vi anstränga oss lite för att kommunikationen ska bli så tydlig som möjligt.

 

Svårt att beskriva förändringarna?

Har man svårt att formulera vad som gjorts i en commit? Då kanske den är för stor och ostrukturerad och den kommer också att bli svår att förstå för den som ska granska. Det är lite som när man namnger sin klass eller sin metod – är det svårt att hitta ett beskrivande namn så mår den nog bra av att designas om.

 

Det är bra att hitta lagom stora changesets som man kan commita, changesets som fortfarande behåller koden i ett stabilt läge och changesets som är tydliga att följa med i och förstå för den som kommer efter dig. Ett ärende kan då komma att bestå av ett flertal mindre sammanhängande commits istället för ett stort, eller flera osammanhängande. Att följa historiken kring det skulle kunna se ut så här:

 

1.

commit 59aeb00854860712bce95d0458f7faea20fbc879 (origin/JIRA-3445, JIRA-3445)

Author: Stefan Nilden <stefan.nilden>

Date:   Tue Sep 15 15:00:39 2020 +0200

    JIRA-3445 Hämta kollektivavtal från försäkring

  • tagit bort tidigare hårdkodat kollektivavtal och ersatt med ett från den aktuella försäkringen
  • lagt till enhetstester
  • tagit bort en del bortkommenterad kod som inte användes

 

2.

commit 67aeb00854860712bce3d0458f7faea20fbc872 (origin/JIRA-3445, JIRA-3445)

Author: Stefan Nilden <stefan.nilden>

Date:   Tue Sep 15 15:03:41 2020 +0200

    JIRA-3445 Hämta kollektivavtal på försäkring

  • fixade till ett integrationstest som inte fungerade längre

 

3.

commit 67aeb00854860212bc5777458faea20fbc903 (origin/JIRA-3445, JIRA-3445)

Author: Stefan Nilden <stefan.nilden>

Date:   Tue Sep 15 15:05:45 2020 +0200

    JIRA-3445 Hämta kollektivavtal på försäkring

  • körde genom koden i sonarlint och rättade till anmärkningar

 

3 olika commits med samma formatering. De är samma rubrik på alla commits som hör till uppgiften och under rubriken listar man upp sina förändringar på ren svenska, eller på det språk som gäller hos er. Det behöver inte vara svårare än så för att skapa en tydlighet även i våra git commits.

Vid pennan/ Stefan Nildén Fullstackutvecklare C.A.G Contactor

 

 

 

 

Kontaktperson

Annika Rogneby

+46 70 687 33 08

annika.rogneby@cag.se

X
X