Er der noget smukkere end en meningsfuld commit history?

God versionsstyring kan spare dig og dine kolleger for meget tid og endnu flere kvaler - hvis du bruger den rigtigt.

afIDA Learning

Har du prøvet at kæmpe dig gennem oceaner af uigennemskuelig diffs og intetsigende commit messages i et næsten håbløst forsøg på at gennemskue, hvilken ændring introducerede en given bug?

Den værdi, du opnår ved at have en god commit history, hvor hver commit gør én ting og hvor commit meddelelsen forklarer kort og præcist, hvad du har lavet og hvorfor - den er nærmest uvurderlig.

Du kan selvfølgelig også bare spørge din kollega, som har lavet ændringen.

Forudsat naturligvis at personen stadig kan huske det - og stadig arbejder hos jer. Ikke er på ferie eller barsel eller bare sidder i et møde og er utilgængelig her og nu, hvor du har brug for at rette en kritisk fejl...

Selv hvis det er din egen kode, er der en god chance for, at du vil være taknemmelig for en god commit history, hvis du pludselig får brug for at genbesøge ændringer, du lavede for et år siden.

Muligheden for let og enkelt at lave en målrettet revert er guld værd.

Det er en af grundene til, at distribuerede versionsstyringssystemer som Git er blevet voldsomt populære de seneste år.

Som versionsstyringssystem er den største fordel netop, at du får en komplet historie for dit projekt fra begyndelse til slut - med muligheden for at vende tilbage til enhver tidligere version samt se forskellene mellem forskellige versioner.

I modsætning til klassiske, centraliserede VCS som Subversion og Team foundation server, er Git et distribueret VCS, hvilket betyder, at hver udvikler har den fulde historie af deres kodelager lokalt - i stedet for at der ligger en hovedfil centralt på en server.

Git hjælper både med versionering af kode, der kommer i produktion, men også ved at sikre gennem branching at features, der ikke endnu er klar til at gå i produktion, bliver isoleret, indtil de er klar.

Sådan skal det gøres

Verden er fuld af rodede, intetsigende commit messages - men der er heldigvis også gode eksempler som Linux kernel og Git itself. De viser, at en velskrevet commit message er den bedste måde at kommunikere konteksten rundt om en ændring. For hvor diff’en nok kan fortælle dig, hvad der har forandret sig, er det kun commit meddelelsen, der fortæller dig, hvorfor.

Men det er vigtigt, du er konsekvent med dine commit meddelelser, for ellers havner du lynhurtigt i en ond cirkel, hvor ingen gider skrive ordentlige commit meddelelser, fordi commit historikken alligevel er ustruktreret og inkonsistent - og fordi den ikke bliver brugt ordentligt, bliver den ved med at være ustruktreret og inkonsistent.

Derfor bør du/dit team begynde med at blive enige om, hvordan en god commit meddelelse ser ud: Hvilke informationer skal de (og skal de IKKE) indholde? Hvordan refererer i til pull request numre etc.?

Generelt er det en god ide at starte med en linje, der kort - og gerne i bydeform - opsummerer din ændring i én linje (maxlængden vil typisk ligge mellem 50 og 72 tegn). Det er den linje, der bliver set af de fleste, så det er vigtigt, at den er sigende.

Vær i den ånd opmærksom på, at en overskrift som “Fix bug” er meget lidt specifik, så beskriv hellere, hvori forandringen består.

Sørg for en tom linje inden et eventuelt uddybende afsnit, der forklarer hvad formålet med ændringen er, hvordan den løser problemet, hvilken effekt har din patch etc. Det, der skal forklares, er med andre ord What og Why, men ikke How.

Virker det svært at opsummere, hvad din commit gør? Så kan det være, det er fordi den indeholder flere forandringer og rettelser. I så fald kan det være en god ide at dele den op i flere forskellige commits.