user Created with Sketch.
Group 2 Created with Sketch.

Introduktion till git (4 av 10)

Inför en kodgranskning och om att arbeta i kod med andra

Än så länge har vi bara arbetat lokalt och det har inte spelat så mycket roll hur våran commit-historik har sett ut, men när man ska dela med sig av sin kod med andra så är det viktigt att ens commit-meddelanden är lättlästa och strukturerade.

Det hände en gång att det hade uppstått en bugg med varianter i systemet så att när kunderna till våra kunders webbshop skulle gå in på en produkt så fanns det med en variant som dom inte kunde lägga i varukorgen, vilket ledde till mycket förvirring och frustration. När våra kunder ringde in till oss så kunde vi snabbt gå in i git-historiken och se vilka ändringar som hade gjorts. När vi kunde se det så kunde också snabbt ändra dom och ladda upp en bugfix. 

Så om våra kunder ringer in till oss angående en bugg så är det mycket lättare för supporten att hitta den ifall commit-historiken ser ut såhär:

Än om den ser ut såhär:


Vi brukar namnge våra commits såhär:

Patch: plugins/order_delay_notification: Prevent notifications for orders before Specter was activated
Patch: address_book: Refactor frontend styling with technical fronten
Release: admin/statistics: Add customer type statistics box
Bugfix: shopping_cart: Fix synchronizing added products.


Det första delen (Patch, Bugfix, Release) indikerar vilken typ av commit det är.
Den andra delen (plugins/order_delay_notification) indikerar var i systemet man har gjort ändringarna. I det här fallet så är ändringen gjort i ett plugin och i funktionen för order_delay_notification.
Den tredje delen efter kolonet beskriver kort vad comitten ska göra.

Syftet med det här är att göra det lätt för andra att se vad vi har gjort, så att dom snabbt och effektivt kan sätta sig in i våran kod. 
 

Se till att du har ett gäng olika commits i din repo och det får gärna se stökigt ut!
  1. Låtsas att du har varit inne och gjort lite olika ändringar. Kanske har du uppdaterat ett plugin till MaltMagnus, eller gjort en buggfix i frontend för Harmoniq eller gjort en optimering av kassan i backend-koden.
  2. Skapa nu en snygg commit-historik som du skulle kunna tänka dig lämna ifrån dig inför en kodgranskning. 
    Testa gärna att skapa många olika commits tills du känner dig bekväm med det.

 

Vanligtvis innehåller en branch bara en eller två commits. Men om man kan dela upp sina ändringar i fler commits så blir det enklare för andra att se vad man har gjort.

Snyggt jobbat!

Valfri text