Lets talk: committing

[MrSebastian]

Im Teammeeting heute wurde das Thema commit-Messages angesprochen. Dabei ging es unter anderem darum dass man auf einen einheitlichen Stil achtet da dies auch für andere Tool nützlich sein können.

Bei uns im Projekt haben wir aktuell keine festen Vorgaben. Daher mein Gedanke dass wir uns dazu austauschen und enstehende Regeln festhalten.

Folgende Punkte sollten wir uns mindestens ansehen:

• Sprache der commit-Message
• Tools für conventional commits
  • wie stark muss bei einem commit der Service erkennbar sein
  • wären gitmojis etwas?
• wollen wir bei PRs squashen?

[MrSebastian]

kurze Zusammenfassung aus einem Vortrag

Konventionen:

• Conventional Commits: <type>[optional scope]: <description> Beispiel: feat(api)!: send an email to the customer when a product is shipped
• Gitmoji: <type>[optional scope] <message> Beispiel: ♻️(components): Transform classes to hooks

Plugins um die Konventionen zu unterstützen/einzuhalten (um eigene Regeln erweiterbar):

• commitlint (Doku)
• commitizen (Doku)
• husky (Doku)

[MrSebastian]

Einen wirklichen Handlungsbedarf sehe ich nicht. Bisher hatte ich wenig Kontakt zu einzelnen Commits.

Meine Meinung ist das wir das bisherige Verfahren grundlegend beibehalten können. Wichtig ist das wir auf thematischen Trennung bei der Umsetzung achten, d.h. wir machen dass was das Issue benötigt. Des weiteren achten auf den Titel des Pull Requests dass dieser die 2. Zeile eines MergeCommit umfasst.
Bei commit-Nachrichten brauchen wir in der Regel nur die Headerzeile. Wenn wir einen Body verwenden sollten wir überlegen ob der Inhalt nicht an andere Stelle gehört, z.b. in die Dokumentation. Ich versuche meine commit-Messages auf Englisch zu verfassen, habe aber dies bezüglich keine Präferenz.

Ein Verweis auf einen Service sehe ich nicht als notwendig da ich über den PR zum Issue und somit via Text oder Label auf den Service komme. Die Wahrscheinlichkeit dass der Service genannt wird erscheint mir zu gering.

Gitmojis wären vermut,ich auf merge-commit ebene Relevant. Dafür wäre aber aktiven eingreifen notwendig. Ich halte für sehr wahrscheinlich dass es vergessen wird. Entsprechende Informationen könnten auch über Labels des Issues gepflegt werden. Bisher haben wir folgende Kategorien: Feature, Bug, Codestyle, Enhancement.