Generator for commit-beskeder

Oprindelse, historie og hvorfor loggen er vigtig

Git gemmer snapshots, men det er commit-beskeden, der forvandler disse snapshots til en historie. På små hobbyprojekter kan man slippe afsted med vage emner, men når et repository har eksisteret i årevis, bliver loggen et værktøj til fejlfinding, revision og onboarding. Mange teams følger stadig ældre mailinglistevaner: en kort emnelinje, eventuelt efterfulgt af en blank linje og en længere forklaring. Konventionelle commits tilføjede et moderne twist ved at standardisere det første token som en type som feat eller fix, eventuelt med et scope, som kan føde automatiserede changelogs og semantiske versionsworkflows.

Effektiv udvælgelse og brug af en besked

Skriv emnet som en kommando

En klassisk retningslinje er at skrive emnet i imperativ: tilføj, reparer, fjern, opdater. Den stil lyder godt, når git sætter præfikset "Hvis anvendt, vil denne commit" foran det. Hold emnet kompakt og konkret, så det stadig giver mening i en logvisning på én linje. Hvis du har brug for baggrund, så flyt den ind i brødteksten, hvor du kan forklare, hvorfor ændringen findes, og hvilke afvejninger du har accepteret.

Brug struktur, når det giver dig fart

Konventionelle commits ser normalt sådan ud: type(scope): subject. Typen grupperer ændringer, scopet peger på et undersystem, og subjektet angiver, hvad du har gjort. Du kan også tilføje en sidefod til ændringer, der ikke fungerer korrekt, eller til referencer til problemer. Nøglen er konsistens: Hvis du vælger typer, så hold listen kort, og hvis du vælger scopes, så hold dem stabile. En streng struktur er ikke en moralsk sejr, det er en måde at gøre anmeldelser, udgivelser og fejlfinding hurtigere.

Vid, hvornår du skal være ligefrem, og hvornår du skal være legesyg

Der er plads til humor, men loggen er også en arbejdsartefakt. I delte repos fungerer en legesyg besked bedst, når den stadig er informativ. Tænk på den som krydderi, ikke måltidet. Hvis du er ved at presse merge, kan du være lidt løsere i mellemliggende commits og derefter omskrive den endelige besked til noget skarpt. Hvis du gemmer alle commits for evigt, så behandl hvert emne som en overskrift, som dine holdkammerater vil søge i senere.

Identitet og teamkultur på én linje

Din commit-stil signalerer, hvordan dit team tænker. Tydelige budskaber reducerer den kognitive belastning under kodegennemgang og gør det lettere at forstå ejerskab. De former også tonen i samarbejdet. Et repo fyldt med "wip" og "stuff" fortæller nye bidragydere, at detaljer ikke betyder noget. Et repo fyldt med læsbare emner og nyttige tekster fortæller dem, at tid og kontekst respekteres. Hvis du arbejder på tværs af tidszoner, er loggen ofte det første sted, hvor du kan tale med en person, du aldrig vil møde live.

Tips til forfattere

• Foretræk én ændring pr. commit, når det er muligt, så emnet kan være specifikt.
• Brug kun type og omfang, hvis de matcher en teamkonvention, du kan overholde.
• Sæt "hvorfor" i brødteksten: begrænsninger, risici og alternativer, du har afvist.
• Referencebilletter i en sidefod eller brødtekst, ikke ved at proppe dem ind i emnet.
• Omskriv før sammenflettet: squash, omformuler og ryd op i støjende mellemtrin.
• Læs emnet alene i en logvisning; Hvis det stadig giver mening, er det klar.

Inspirationsprompts

Når du sidder fast, så brug disse spørgsmål til at finde det rigtige emne, der gemmer sig inde i diff'en.

• Hvilken brugersynlig adfærd ændrede sig, og hvordan ville du beskrive det med ét verbum?
• Hvilket undersystem berører dette, og ville et stabilt omfang hjælpe korrekturlæsere med at scanne?
• Har du rettet en regression, lukket en kantsag eller tilføjet en sikkerhedsvagt?
• Hvad ville gå i stykker, hvis du tilbageførte denne commit i morgen?
• Hvilket kompromis accepterede du: hastighed, hukommelse, læsbarhed eller kompatibilitet?
• Hvad er det mindste ærlige emne, der stadig peger på det rigtige resultat?

Hvad er gode idéer til commit-beskeder?

Der er tusindvis af tilfældige idéer til commit-beskeder i denne generator. Her er nogle eksempler at begynde med:

• fix(ui): add rate limit backoff
• feat(cache): implement api error handling
• perf(tests): guard audit trail
• simplify routing table for slow networks
• guard rate limit backoff under load
• tighten audit trail (refs #1217)
• remove render pipeline for windows
• add rate limit backoff (refs #1522)
• wire feature flag toggle for staging
• ship it render pipeline and pretend it was intentional