Konventionella commits kommer inte rädda dina commitmeddelanden

En snabb sökning på internet avslöjar ett överflöd av artiklar som lär dig hur man skriver commitmeddelanden. 90 % av dessa artiklar säger åt dig att använda konventionella commits. Dock kämpar en ansenlig mängd utvecklare fortfarande med detta. De vet att de borde följa dessa konventioner, men de tycker att det är svårt att tillämpa dem i praktiken. Varje gång de commitar kod plågas de över om de ska skriva "refactor" eller "chore". Jag har till och med sett projekt där commitmeddelandelistan består helt av samma meddelande: "feat: add page", eftersom det blev för svårt för dem att skriva commitmeddelanden, och de helt enkelt gav upp.

Det är för tidigt att prata om konventionella commits#

Jag säger inte att konventionella commits är dåliga. De har många välkända fördelar:

• De ger ett enhetligt format, vilket gör commitmeddelanden mer standardiserade
• De är lätta för automatiserade verktyg att analysera, vilket möjliggör automatisk generering av changelogs
• De hjälper teammedlemmar att förstå syftet och omfattningen av kodändringar
• De möjliggör snabb identifiering av olika typer av kodändringar

Men när en utvecklare fortfarande kämpar med att skriva bra commitmeddelanden även efter att ha använt konventionella commits, är det faktiskt meningslöst att kasta en artikel på dem om hur man använder konventionella commits, att lära dem vad typen feat betyder, vad typen fix betyder. Det är som att ge en avancerad kokbok till någon som inte vet hur man lagar mat, utan att lära dem hur man använder grundläggande ingredienser och köksredskap. Ändå finns sådana artiklar överallt på internet. De förstår inte att konventionella commits bara kan vara riktigt effektiva när utvecklare har ett klart tänkande och förmågan att dela upp uppgifter precist.

Så, konventionella commits är inte dåliga, men innan vi kommer dit, behöver vi etablera rätt utvecklingsmentalitet och använda vetenskapligt utvecklartänkande för att göra saker.

Viktigt tänkande för att skriva bra commitmeddelanden#

Kodändringar bör göra en sak i taget#

Inom mjukvaruutveckling är "gör en sak i taget" en viktig princip. Detta gäller inte bara när du skriver kod utan även när du commitar kod. När vi fokuserar på en specifik uppgift eller ändring åt gången blir vår kod tydligare och våra avsikter mer uttalade. Denna metod förbättrar inte bara kodens läsbarhet utan förenklar också granskningen av koden avsevärt. Granskare kan lättare förstå och verifiera syftet med varje ändring.

Dessutom ger denna metod bekvämlighet för potentiella återdragningar av kod. Om problem uppstår kan vi lättare lokalisera och återställa specifika ändringar utan att påverka andra, orelaterade delar. Framför allt, när varje ändring bara gör en sak, blir commitmeddelandet som beskriver denna ändring naturligt mer precist och meningsfullt.

I praktiken innebär detta att vi behöver tydligt definiera den uppgift som ska utföras innan vi börjar koda. Efter att ha slutfört en uppgift bör vi omedelbart commita koden istället för att vänta tills flera uppgifter är slutförda innan vi commitar tillsammans. Om vi upptäcker andra områden som behöver modifieras medan vi slutför den nuvarande uppgiften, är det bästa tillvägagångssättet att anteckna dem och hantera dem separat efter att ha avslutat den aktuella uppgiften. Till exempel, när du implementerar en funktion och upptäcker några befintliga buggar, bör du inte fixa buggen direkt tillsammans med din nya funktionskod, utan snarare implementera funktionen först och sedan fixa buggen du upptäckte i en annan commit, eller fixa buggen först och sen commita funktionen.

Commitmeddelanden finns faktiskt innan vi skriver kod#

Många utvecklare börjar bara tänka på hur man skriver commitmeddelanden efter att koden är klar, men i verkligheten bör commitmeddelanden finnas innan vi börjar koda. Detta eftersom commitmeddelanden i huvudsak återspeglar de steg vi tar för att slutföra en uppgift. Med andra ord är de våra att-göra-uppgifter.

När vi börjar en uppgift bör vi först tänka på vilka specifika steg som behövs för att slutföra denna uppgift. Dessa steg är vår att-göra-lista och samtidigt våra framtida commitmeddelanden. Med denna att-göra-lista har var och en av våra kodändringar ett syfte, håller oss fokuserade medan vi kodar och förhindrar att vi avviker från uppgiften.

Viktigare är att denna metod kan avsevärt förbättra vår effektivitet. När vi avslutar ett steg är det motsvarande commitmeddelandet redan förberett, och vi kan använda det direkt, vilket minskar tiden vi spenderar på att tänka på hur man beskriver ändringen. Samtidigt, eftersom dessa commitmeddelanden är klara när vi har en helhetsförståelse av uppgiften, är de vanligtvis av högre kvalitet och mer informativa.

Anta att du behöver implementera en ny användarregistreringsfunktion. Du kan planera dina uppgiftssteg så här:

1. Refaktorera den befintliga formulärkomponenten för att göra den mer generell och återanvändbar
2. Skapa ett användarregistreringsformulär
3. Implementera API-integrering för användarregistrering
4. Lägg till enhetstester för användarregistreringsfunktionen
5. Uppdatera dokumentationen för användarregistreringsfunktionen

De commitmeddelanden som motsvarar dessa uppgiftssteg kan vara som följer:

1. refactor: förbättra befintlig formulärkomponent för återanvändbarhet
2. feat: skapa användarregistreringsformulär
3. feat: implementera användarregistrerings-API-integrering
4. test: lägg till enhetstester för användarregistrering
5. docs: uppdatera dokumentation för användarregistreringsfunktion

På så sätt har du klara uppgiftssteg och motsvarande koncisa commitmeddelanden innan du börjar koda. Dessa commitmeddelanden är faktiskt din att-göra-lista och guidar dig genom hela processen att implementera funktionen.

När du avslutar varje steg kan du använda det motsvarande commitmeddelandet för att commita din kod. Detta hjälper dig inte bara att bättre organisera och genomföra uppgifter, utan säkerställer också att varje commit fokuserar på ett specifikt steg, vilket gör hela utvecklingsprocessen tydligare och mer hanterbar. Om du behöver justera commitmeddelandet något under den faktiska kodningen kan du göra mindre ändringar för att mer exakt beskriva de faktiska ändringarna.

Konventionella commits blir ett naturligt val#

När vi utvecklar rätt utvecklingsmentalitet blir användandet av konventionella Commits naturligt. I detta skede kommer du upptäcka att det blir enkelt att välja rätt typ-prefix (såsom feat, fix, refactor, etc.) eftersom dina commitmeddelanden redan tydligt återspeglar dina uppgiftssteg.

Om du vill lära dig mer om hur man använder konventionella commits finns det många utmärkta artiklar tillgängliga online. Men glöm inte att dessa standarder endast kan vara riktigt effektiva när de är byggda på grunden av rätt utvecklingsmentalitet.

Slutsats#

Att skriva bra commitmeddelanden handlar inte bara om att följa ett visst format. Det kräver att vi bibehåller ett klart tänkande under utvecklingsprocessen, klargör syftet med varje ändring, och funderar på hur vi ska beskriva vårt arbete innan vi börjar koda.

Konventionella commits är verkligen ett användbart verktyg, men de kan bara uppnå sin maximala effekt när de kombineras med rätt utvecklingsmentalitet. Genom att praktisera de två principerna "gör en sak i taget" och "tänk på commitmeddelanden i förväg", kan vi inte bara förbättra kvaliteten på commitmeddelanden utan också öka den övergripande utvecklingseffektiviteten och kodkvaliteten.

Jag hoppas denna artikel hjälper dig att ompröva din utvecklingsprocess och uppmuntrar dig att pröva dessa metoder. Kom ihåg att goda utvecklingsvanor tar tid att odla, men när de väl bildats kommer de avsevärt förbättra din arbetseffektivitet och kodkvalitet.