Boehrsi.de - Blog

Git - Conventional Commits Spezifikation für Commit Messages

Erstellt am event Uhr von account_circle Boehrsi in label Development
Git - Conventional Commits Spezifikation für Commit Messages Bild

Git ist ein tolles Tool um Code und andere Inhalte zu verwalten, egal ob alleine oder gemeinsam. Ich habe mittlerweile alles was nicht nur ein kleiner Test ist in Git Repositories. Im Rahmen der Nutzung von Git gibt es diverse unterschiedliche Ansätze und Meinungen, wie man Dinge angehen soll und was die jeweilige Best Practice ist.
Im Bereich der Commit Messages habe ich in der letzten Zeit immer mehr Wildwuchs in meinen Projekten bemerkt, obwohl ich eigentlich versucht habe die Dinge überall ähnlich zu benennen. Wichtig ist dies z.B. wenn man später nach Dingen sucht oder z.B. automatisiert Release Notes aus den Commit Messages generieren will.
Durch Zufall bin ich auf die Conventional Commits Spezifikation in einem Flutter Plugin Repository gestoßen und fand den Ansatz sehr passend. Das Ganze basiert auf Ideen des Semantic Versioning open_in_new und der Angular Entwickler Community open_in_new. Die Conventional Commits Spezifikation erweitert die Ideen und Ansätze um feste Richtlinien. Mich persönlich interessiert vor allem der Prefix für Commit Messages, denn eben dieser ist ohne viel Aufwand gesetzt, hilft aber bei den oben genannten Punkten sehr.

Ich stelle aktuell gerade alle meine Repositories um, sodass ich überall den entsprechenden Prefix setze und versuche Indikatoren für Breaking Changes (ein Ausrufezeichen hinter dem jeweiligen Prefix) zu nutzen. Ich orientiere mich dabei an der Spezifikation, füge aber nach Bedarf eigene Typen als Prefix hinzu. Aktuell arbeite ich mit folgender Liste:

  • feat: Neue Funktion hinzugefügt
  • fix: Bugfix
  • docs: Änderung an der Dokumentation
  • style: Formatierung angepasst, Imports optimiert und ähnliches
  • refactor: Refactoring des Codes ohne Funktionsänderung
  • test: Änderung an den Tests
  • chore: Kleinere Nebenaufgaben, wie z.B. Abhängigkeiten aktualisieren
  • build: Änderungen am Build-System oder der CI
  • content: Neuer Inhalt hinzugefügt
  • perf: Performance Optimierung

Derzeit komme ich mit diesen Typen gut klar und nutze sie ausgiebig. Der Mehraufwand ist quasi gleich null, dafür sind aber diverse Dinge einheitlicher. Wie bei vielen anderen Sachen gilt auch hier, alles ist Geschmackssache, aber ich denke eine einheitliche Benennung von Dingen ist immer hilfreiche. Welche Spezifikation man wählt ist natürlich aber jedem selbst überlassen. Wie geht ihr mit diesem Thema um?

Related Links
Kommentare  
Kommentar erstellen
Mit dem Abschicken des Kommentars erklären sie sich mit der in der Datenschutzerklärung dargelegten Datenerhebung für Kommentare einverstanden. Spam, unangebrachte Werbung und andere unerwünschte Inhalte werden entfernt. Das Abonnieren via E-Mail ist nur für E-Mail Adressen erlaubt die Sie rechtmäßig administrieren. Widerrechtliche Abonnements werden entfernt.