Hört auf, Conventional Commits zu verwenden

(sumnerevans.com)

4 Punkte von GN⁺ 2026-06-06 | 2 Kommentare | Auf WhatsApp teilen

Conventional Commits versuchen, Commit-Messages im Format <type>[optional scope]: <description> mit Bedeutung zu versehen, stellen dabei aber den Änderungstyp in den Vordergrund und machen den Geltungsbereich optional, sodass die für die tatsächliche Navigation nötigen Informationen nach hinten rücken
Beitragende, Debugger und Incident-Responder suchen im Commit-Log nach den Codebereichen, die von einer Änderung betroffen sind; da Bugs bei jeder Art von Änderung entstehen können, ist der scope wichtiger als der Typ
Bei fix(compiler): prevent namespaced SVG <style> elements from being stripped erkennt man schon an der Beschreibung, dass es sich um einen Bugfix handelt, und refactor(core): Update webmcp support to use document.modelContext zeigt, dass ein einzelner Commit zugleich Bugfix, Refactoring und Feature-Erweiterung sein kann — der type ist also redundant und einschränkend
Die automatische Erzeugung von CHANGELOGs und die Ableitung semantischer Versionssprünge haben Grenzen, weil Commit-Logs und Changelogs unterschiedliche Leser haben und Reverts, versehentliche Breaking Changes oder später behobene Inkompatibilitäten das Ergebnis verzerren können
Commit-Messages mit scope-Präfix zeigen zuerst, was tatsächlich geändert wurde, und auch Build- und Deployment-Bedingungen sollten besser auf per git diff ermittelten geänderten Dateien basieren als auf dem Typ im Titel

Falsche Prioritäten

Conventional Commits verfolgen das Ziel, Commit-Messages mit Bedeutung zu versehen, damit Entwickler und Endnutzer Änderungen besser verstehen können

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Die Betreffzeile besteht aus einem <type> wie fix, feat, chore, docs oder refactor, einem optionalen scope und einer Beschreibung
Der zentrale Mangel ist die Struktur, die den Änderungstyp über den scope stellt, also über den eigentlichen Gegenstand der Änderung
Dass der scope optional ist, erlaubt es, dass die wichtigste Information eines Commits fehlen kann, und dass der Typ ganz am Anfang steht, kehrt die Prioritäten um

Warum scope wichtiger ist als type

Beitragende lesen das Commit-Log, um Änderungen seit ihrem letzten Beitrag nachzuvollziehen, den Gesamtfluss eines Projekts zu verstehen und Commits zu finden, die beim Pullen oder Rebasen mit ihrer laufenden Arbeit kollidieren könnten
Debugger suchen nach Änderungen, die Bereiche berührt haben, die mit der fehlerhaften Komponente zusammenhängen; da Bugs bei jedem type von Änderung entstehen können, hilft die Typinformation dabei nicht
Incident-Responder überfliegen das Commit-Log rund um den Zeitpunkt einer Störung, um den betroffenen Bereich zu finden; wenn an der Stelle eines starken Anstiegs von Inbound-API-Fehlern ein Commit mit dem scope auth steht, ist das ein naheliegender Kandidat als Ursache
Für Menschen, die Commit-Logs lesen, ist nicht entscheidend, welcher Art eine Änderung war, sondern welchen Bereich sie berührt hat

Die Redundanz und Begrenztheit von type

fix(compiler): prevent namespaced SVG <style> elements from being stripped zeigt schon in der Beschreibung, dass es ein Bugfix ist; der type fix ist daher redundant
Der Platz in der Commit-Betreffzeile ist begrenzt, daher hilft es nicht, Zeichen für einen type zu verbrauchen, den man bereits aus der Beschreibung erkennen kann
refactor(core): Update webmcp support to use document.modelContext aktualisiert die webmcp-Funktionalität der core-Komponente so, dass sowohl document.modelContext als auch navigator.modelContext unterstützt werden
Diese Änderung lässt sich gleichzeitig als Bugfix, Refactoring und neues Feature verstehen, aber die tatsächlich wichtige Information ist, dass es sich um eine Änderung an der Komponente core/webmcp handelt

Grenzen des Automatisierungsversprechens

Die Idee, mit Tools wie git-cliff oder conventional-changelog automatisch aus Commits ein CHANGELOG zu erzeugen, hat das Problem, dass Commit-Logs und Changelogs unterschiedliche Zielgruppen haben
Ein CHANGELOG richtet sich an Nutzer und fokussiert sich darauf, funktionale und geschäftliche Unterschiede zwischen Versionen verständlich zu machen
Ein Commit-Log richtet sich an Entwickler und dient dazu, nachzuvollziehen, wie sich die Codebasis im Zeitverlauf verändert hat und wie sich Änderungen aus Sicht des scope entwickelt haben
In Projekten mit mindestens mittlerer Komplexität wird ein sinnvolles Feature oft über mehrere Commits eingeführt; für Entwickler ist der Implementierungsprozess nützlich, für Endnutzer ist nur das fertige Feature relevant
Revert-Commits sind für Entwickler im Fluss des Commit-Logs wichtig, für Endnutzer ist eine zurückgenommene Änderung jedoch gleichbedeutend mit einer Änderung, die nie ausgeliefert wurde
Semantische Versionssprünge auf Basis von Commit-Typen können dazu führen, dass trotz eines revertierten Breaking Changes eine Major-Version erhöht wird, dass erst später erkannte Inkompatibilitäten fälschlich als Minor- oder Patch-Version veröffentlicht werden oder dass etwas als Breaking Change gilt, obwohl der Bruch durch Folge-Commits wieder verschwunden ist
Solche Situationen lassen sich zwar per Rebase aus der Historie herauskorrigieren, aber der Workflow kann das verhindern oder beschädigen und damit die Verlässlichkeit des im Commit-Log vermittelten Verlaufs mindern
Wenn Build- oder Deployment-Prozesse durch den type im Commit-Titel ausgelöst werden, können automatische Werkzeuge umgangen werden, etwa wenn ein Commit mit dem Titel docs: fix typos in Wirklichkeit eine Schwachstelle im Authentifizierungs-Subsystem einführt
Es ist besser, Build- und Deployment-Bedingungen anhand der mit git diff ermittelten geänderten Dateien festzulegen als anhand des Commit-Titels

Umsetzungsprobleme und Alternativen

Conventional Commits empfehlen, projektspezifische type-Sets zu definieren, doch viele Projekte übernehmen schlicht die Standardtypen von commitlint, die möglicherweise nicht gut zu den Besonderheiten des jeweiligen Projekts passen
Die Spezifikation von Conventional Commits definiert technisch gesehen nur fix und feat; weitere Typen bleiben dem jeweiligen Projekt überlassen
In Unternehmensumgebungen kann es aufgrund von Change-Management- und Audit-Anforderungen nötig sein, in jede Commit-Message eine Ticketnummer aufzunehmen; wenn <scope> dafür verwendet wird, geht nützliche Metadaten verloren
Linux, FreeBSD, Git, Go, NixOS und Node.js verwenden projektgerechte Commit-Messages mit scope-Präfix

Projekt	Format	Beispiel
Linux	`subsystem: description`	`i2c: virtio: mark device ready before registering the adapter`
FreeBSD	`prefix: Description`	`linuxulator: Return EINVAL for invalid inotify flags`
Git	`area: description`	`gitlab-ci: update macOS image`
Go	`package: description`	`net/http/cookiejar: add godoc links`
nixpkgs	`pkg-name: description`	`xwayland: 24.1.11 -> 24.1.12`
Node.js	`subsystem: description`	`stream: fast-path stateless transform flush results`

Im Linux-Kernel ist das subsystem ein natürlicher scope, in Go-Projekten der Package-Pfad und in Microservice-Architekturen der Name des jeweiligen Microservice
scopedcommits.com plädiert für eine Rückkehr zu einem scope-zentrierten Format bei Commit-Messages und für die Trennung von CHANGELOG-Erzeugung und Commit-Log-Verwaltung
Die Vorteile von Conventional Commits haben sich in der Praxis nicht in echte Vorteile übersetzt, und ihre Popularität in Open-Source-Projekten sowie die Tendenz von KI, sie standardmäßig zu wählen, haben zur Verbreitung von Commit-Messages mit vermischten Antipatterns geführt

2 Kommentare

GN⁺ 2026-06-07

Hacker-News-Kommentare

Programmierer scheinen immer darüber zu diskutieren und sich zu beschweren, was die optimale Einstellung ist, selbst bei Kleinigkeiten wie Tabs und Spaces
Das heißt nicht, dass Conventional Commits die gottgegebene, beste Art sind, Commit-Messages zu schreiben, aber ich denke, eine festgelegte Struktur zu haben und die Erwartungen an Commit-Messages anzugleichen, ist deutlich effektiver und wichtiger
Der Autor betont stark, dass der Scope wichtiger sei als der Typ, aber ich glaube nicht, dass der Unterschied zwischen fix(compiler) und compiler fix eine Frage von Leben und Tod ist
In der Tech-Branche gibt es viele Dinge, die vielleicht nicht optimal sind, aber trotzdem zum Standard wurden; bei JSON würden zum Beispiel viele sagen, dass man, wenn man es heute neu entwerfen würde, Kommentare, klarere Zahlenformate usw. unterstützen sollte
Trotzdem wurde es zum Standard, weil es in vielerlei Hinsicht besser war als das Vorherige, und auch wenn es vielleicht ein etwas besseres Format als Conventional Commits gibt, scheint es nicht so viel besser zu sein, dass es sich lohnt, noch eine weitere konkurrierende Struktur für Commit-Messages einzuführen
- Eine definierte Struktur ist nicht gleichbedeutend mit Qualität
  Eine Commit-Message kann mit lockerer Struktur hervorragend sein, wenn sie die Art der Änderung gut vermittelt, und umgekehrt kann sie trotz sehr formaler Struktur verwirrend oder inhaltsleer sein
  Im Großen und Ganzen stimme ich dem Autor zu: Conventional Commits lösen das eigentliche Problem schlechter Commit-Messages nicht
- Für Standardisierung an sich bin ich, aber mit dieser Logik kann man auch jeden zweitbesten Status quo immer weiter rechtfertigen
  XML ist gut genug und ein Standard, SOAP ist gut genug und ein Standard
  Die Aussage ist also, dass Conventional Commits gut genug und ausreichend standardisiert sind, sodass sich eine andere Struktur nicht lohnt, aber dieser „Wert“ ist subjektiv
  Wenn man täglich Commits macht und PRs liest, kann sich auch die kleine Reibung durch das Conventional-Commits-Format summieren, und wenn man das nicht wie ein Naturgesetz behandelt und Alternativen zulässt, hilft das Teams, die etwas anderes bevorzugen
  Die meisten Teams generieren ohnehin keine Changelogs
- Ich hänge emotional nicht besonders an dieser Debatte, aber die Gegenargumente im Originaltext klingen auf mich hohl
  Dass der Scope wichtig ist, stimmt, aber lässt sich das nicht aus dem Commit-Inhalt ableiten?
  Beim Prüfen eines Diffs ist es ein wichtiger Sanity-Check, auf die betroffenen Pfade zu schauen, und ein „test“-Diff sollte keinen Produktions-Authentifizierungscode verändern
  Wenn ich es aber in --oneline sehen will, dann ist feat(auth): besser als feat:
  Ich stimme auch nicht der Behauptung zu, dass die Zielgruppe falschliegt
  Ein feat-Commit sollte tatsächlich Änderungen aus Produktsicht beschreiben, und man sollte die sinnlosen Refactoring-Änderungen zuerst sauber stapeln und dann die kleine neue Funktionsänderung obendrauf legen
  Das ist auch das Nützlichste, was man in eine Diff-Beschreibung packen kann, und technischer Kontext wie „Warum wurde Algorithmus X gewählt?“ sollte in Kommentaren oder in DECISIONS.md stehen, damit er nicht verloren geht
  In einem schnelllebigen Unternehmen kümmern sich wahrscheinlich nur pedantische Leute um solche langweiligen Dinge in der Commit-Historie, aber in Open-Source-Projekten ist es viel wichtiger, Kontext in Commit-Messages zu hinterlegen
- Der Kernpunkt ist nicht, dass der Scope wichtiger ist als der Typ, sondern dass sich mit natürlicher Sprache betonen lässt, was man für wichtig hält; wenn man aber alles in ein bestimmtes Format presst, geht diese Information verloren
  Es gibt einen Grund, warum es Formate wie Markdown und Plaintext gibt und nicht nur JSON
- Ich halte Conventional Commits für eine gute Idee, weil man Menschen mit Tools dazu zwingen kann, zumindest ein kleines bisschen über ihre Commit-Message nachzudenken
  Ich habe viel zu viele Commits reviewt, deren Titel small fix lautete, obwohl es in Wirklichkeit überhaupt keine kleine Änderung war
Die eigentliche Schlussfolgerung ist, dass jedes Projekt andere Anforderungen hat
In mehr als 30 Jahren mit Versionsverwaltung habe ich kein einziges Mal erlebt, dass es nützlich gewesen wäre, Komponenten in der Beschreibung auf standardisierte Weise anzugeben (im Artikel als Scope bezeichnet)
Schon allein daran, wo die betroffenen Dateien im Quellbaum liegen, ist klar, welche Komponente geändert wurde, und bug, fix oder feature stiften ebenfalls keinen nützlichen Mehrwert
Wäre es nicht wichtig gewesen, wäre es nicht eingecheckt worden
Das Einzige, was ich als nützlich empfunden habe und was im Artikel überhaupt nicht behandelt wird, sind Links oder IDs zu zugehörigen Change Requests
In einem Commit steht bereits, was geändert wurde; was fehlt, ist der Kontext, warum es geändert wurde
Selbst in persönlichen Projekten setze ich vor die Beschreibung einen JIRA-Verweis in eckigen Klammern, und selbst wenn ich unterwegs zufällig etwas mitfixe, erstelle ich ein kurzes einzeiliges JIRA, hole mir eine ID und schreibe dort den Grund hinein
- Das „Warum“ ist genau der Inhalt, der in eine git-Commit-Nachricht gehört
  Das Erfassen des „Warum“ ist der gesamte Zweck dieser Nachricht, und ein externer Link auf eine Ressource, die irgendwann verschwinden kann, ist kein guter Ersatz
- Als wir JIRA verwendet haben, haben wir das auch so gemacht
  Bei GitHub-Issues kann man vom Commit zur PR-Diskussion zurückgehen, und diese PR sollte verknüpfte Issues und andere Verweise enthalten
  Natürlich haben wir JIRA beim Umstieg auf GitHub-Issues fast vollständig aufgegeben, und ein paar Jahre später wurde die Instanz abgeschaltet und gelöscht
  Jetzt sind all diese JIRA-Tags vollständig nutzlos
  Deshalb denke ich eher, dass es eine starke Kopplung zwischen Issue-Tracker und git-Repository braucht
  Was man wirklich will, ist Portabilität, aber ich weiß nicht, wie man die ohne starke Kopplung erreichen soll
  Im Idealfall gäbe es ein offenes Standardformat, aber in der Realität ist GitHub der gigantische Gorilla, der das Format definiert, und wenn Klone wie GitLab GitHub-Projektmetadaten oder zumindest PRs importieren können, kommt das der Sache praktisch schon nahe
  Jedenfalls ist eine Richtlinie, unveränderliche Zeiger auf Atlassian-Produkte zu hinterlassen, die man in fünf Jahren vielleicht nicht mehr nutzt, keine gute Idee
  Eher würde ich eine Richtlinie akzeptieren, nach der ein git-Commit vollständig für sich allein stehen und alle Informationen zum „Warum“ einer Änderung in die Commit-Nachricht oder in Quellcode-Kommentare einfließen sollten
  Allerdings halte ich auch das für fehleranfällig, weil Menschen in git-Commits zu knapp schreiben, beim Zusammenfassen von Issues Informationen verlieren und die Hin-und-her-Diskussion in PRs nützlich ist, weil sie mehr enthält als nur eine Zusammenfassung der Begründung in einer einzigen Stimme
- Für automatisch erzeugte Release Notes ist es nützlich
  Wenn man neue Funktionen zuerst gruppiert und danach Fehlerbehebungen aufführt, ist das für nichttechnische Nutzer etwas leichter zu lesen
- Stimmt
  Commit-Nachrichten sind nicht dafür da, Changelogs zu erzeugen, sondern für zukünftige Entwickler
  Der wichtigste Moment, in dem dieser Entwickler eine Commit-Nachricht liest, ist der, in dem er nicht versteht, warum der Commit existiert
  Es geht dann nicht darum, was geändert wurde, sondern welchen Zweck eine bestimmte Zeile hat
  Deshalb führt man blame aus und schaut sich den Commit an, der ursprüngliche Entwickler hat das Unternehmen längst verlassen, das alte JIRA könnte verschwunden sein, und der einzige Hinweis ist die Commit-Nachricht
  https://dev.to/splix/the-why-behind-the-code-2bb1
- Ist der Vorteil einer separaten Quelle, dass man Dinge wie Bilder einfügen kann, oder übersehe ich etwas?
  Könnte man den Kontext nicht einfach in den Commit-Text aufnehmen?
Das Wort chore, das viele Nutzer von Conventional Commits verwenden, hat mich immer gestört
Persönlich habe ich stattdessen immer Commit-Titel im Linux-Kernel-Stil bevorzugt, was hier glücklicherweise ebenfalls erwähnt wird
[0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
- Stimme vollständig zu
  Die Haltung, die chore andeutet, finde ich äußerst abstoßend
  Es wirkt, als müsste alles andere mit fun oder indifferent markiert werden, und solche emotionalen Wertungen gehören nicht in Commit-Nachrichten
- Ich habe ein Ersatzwort gefunden: upkeep
  Gleiche Bedeutung, aber ohne den herablassenden Unterton
- Dir könnte auch Richs Artikel gefallen: https://richvdh.org/conventional-commits-considered-harmful....
- Der Begriff ist tatsächlich schlecht
  Außerdem tut er so, als wüsste man im Voraus, welche Gesamtwirkung ein Commit hat, obwohl man das in Wirklichkeit nicht weiß
  Mit Conventional Commits müssen sowohl Teammitglieder als auch LLMs Zeit und Tokens darauf verwenden, diese dumme Nomenklatur zu produzieren
Mein Hauptkritikpunkt an Conventional Commits war, dass in Commit-Titeln Issue-Nummern nicht enthalten sind
In der Standardspezifikation werden sie nicht einmal als optional erwähnt
Für mich ist das fast die wichtigste Information in einer Commit-Nachricht
Ich kann gar nicht sagen, wie oft ich in den letzten 15 Jahren die Beschreibung eines von einem alten Commit referenzierten Issues gegengeprüft habe, um den vollständigen Kontext einer Änderung zu verstehen
Ich hatte das für eine Art Standardgewohnheit gehalten, aber erst als ich Conventional Commits kennenlernte, habe ich gelernt, dass dem nicht so ist
Ich habe überhaupt nicht verstanden, warum das populär ist
- Persönlich bevorzuge ich es, Issues als git trailer anzuhängen
  fix thing in foo
  
  Issue: ABC-123

Git hat viele eingebaute Funktionen zum Parsen und Formatieren solcher Trailer, daher kann man leicht benutzerdefinierte git log-Aliasse erstellen, um sie inline anzuzeigen oder in CI zu parsen.

Wenn man ohnehin schon ein Changelog mit begrenzter Zeichenzahl durchsieht, interessiert einen XYZ-999999 in der Haupt-Commit-Nachricht eher wenig.
Es ist gut, per Trailer zu taggen, aber ich möchte viel eher sehen, was der Commit getan hat, als eine Jira-Issue-Nummer.
Ich halte es nur dann für ein Problem, wenn verlangt wird, dass der Issue-Key zwingend ganz am Anfang des Titels stehen muss.
Auch dann finde ich, dass das der Lesbarkeit schadet.
Ich verstehe nicht, warum man ihn nicht einfach irgendwo hinter dem ganzen sonstigen Conventional-Commits-Format anhängen kann.
Ein Issue-Key sollte sich ohnehin per Regex herausziehen lassen, etwa als Zahl nach einem alphanumerischen Präfix, daher braucht so ein „Standard“ kaum eigens dafür reservierten Platz.
Persönlich nutze ich ohne Conventional Commits am Ende Klammern, wenn der Commit mit dem betreffenden Issue zusammenhängt.
Wenn die Beziehung stärker ist, etwa dass das Issue dadurch behoben wird, füge ich zusätzlich einen Fixes-Trailer in die Nachricht ein.
Interessant.
Wir haben bisher fix(ABC-123): some message here verwendet, und das wird gut verlinkt und in automatisch erzeugten Release Notes auch sehr schön gerendert.
Das ist kein Standard, sondern eine Konvention.
Ihr könnt im Team einfach einen Standard festlegen, nach dem Ticket-IDs in Commit-Nachrichten enthalten sein sollen.
Wenn es maschinenlesbar sein soll, kann man einfach Footer/Trailer verwenden.
Über Conventional Commits kann ich nichts Gutes sagen.
Das Format nimmt in dem Teil der Nachricht Platz weg, der am häufigsten gelesen wird, und Kategorien oder Typen haben wenig Informationsgehalt.
Ehrliche englische Verben als normaler Satz im Titel leisten dasselbe, und ein richtiger Satz liest sich viel besser als drei Arten von Satzzeichen wie :, () und !.
Mit einem „Bereich“ im Titel kann ich noch leben, und auch das gab es schon vor dieser Konvention.
Bei der Arbeit bauen wir Web-Apps für nichttechnische Nutzer, und Changelogs für diese Nutzer kann man gut auf Norwegisch schreiben.
Commit-Nachrichten sind für Nutzer irrelevant, und dass jeder Commit gut genug sein müsste, um im Endnutzer-Changelog zu landen, wird bei uns so bald nicht passieren.
Stattdessen kann man einfach Footer/Trailer verwenden.
Wirklich hilfreich sind Conventional Commits bei Continuous Deployment.
Man kann bei jedem Merge nach main automatisch SemVer-Tags setzen und deployen, weil die für Tagging und Versionsverwaltung nötige Entscheidung bereits getroffen wurde, als der Entwickler die Commit-Nachricht geschrieben hat.
Ich erkenne vollkommen an, dass das nicht zu riesigen Projekten wie dem Linux-Kernel passt.
Aber bei 99 % der Projekte verbessert die Kombination aus Conventional Commits und SemVer den aktuellen Release-Prozess erheblich und lässt sich leichter automatisieren.
- Selbst im Continuous-Deployment-Kontext mag ich einen Ansatz, der auf git tags basiert.
  git describe reicht für Versionsverwaltung im Continuous Deployment oft aus, und v1.2.3-4-gabcdef beschreibt einen Commit so genau, wie Git es für ausreichend hält, und ist SemVer ähnlich genug, um Erwartungen zu setzen.
  Das gilt besonders dann, wenn neue git tags nur nach menschlicher Entscheidung gesetzt werden, etwa: Das hier ist eine Breaking Change, also sollten wir jetzt eine neue Major-Version taggen.
  Bei Versionsnummern im git describe-Format dreht sich der eigentliche Streit im Wesentlichen nur darum, ob man den ersten Bindestrich durch ein Plus ersetzt, um besser zu den SemVer-Erwartungen zu passen; und wenn es einen Mehrwert hat, SemVer-Erwartungen durchzusetzen, etwa damit Paketmanager Versionen korrekt sortieren, kann man das mit einer einfachen Regex umschreiben.
  git describe macht CD-Automatisierung einfach, überlässt die Entscheidung über Versionsnummern aber Menschen über die Auswahl von git tag oder GitHub Releases, statt anhand von magischen Schlüsselwörtern in der Commit-Historie zu raten.
- In meinen Open-Source-Projekten nutze ich diesen Ansatz, um SemVer-Erhöhungen zu automatisieren, und er ist wirklich gut.
  Bei der Arbeit erzwingen wir je nach Zielgruppe, die sich für die Änderung interessiert, auch „Tags“.
  Mit Tags sind hier keine Git-Tags gemeint, sondern Strings im PR-Titel, und auf Basis dieser „Tags“ erzeugen wir teambezogene Changelogs.
- Im Artikel wird erklärt, warum das nicht richtig funktioniert.
- Aber warum muss das im Titel stehen?
  Wenn man auf diese seltsame Weise versionieren will, kann man doch einfach eine magische Formulierung in den Commit-Body schreiben.
  Dann ist man auch nicht auf ein einziges Wort beschränkt.
Ich mag diesen Titelstil ziemlich wenig.
Formulierungen wie „Stop something“ scheinen sehr beliebt zu sein; sie sind imperativ und vermitteln das Gefühl von „Ich habe definitiv recht“.
Ich verstehe nicht, warum man nicht so etwas wie „In favour of something“ oder „A case against something“ schreibt.
- Ich verstehe nicht, warum man nicht direkt und klar die bevorzugte Position vertreten sollte.
  Man muss dieser Position ja nicht zustimmen, aber zu verlangen, die Formulierung abzuschwächen, ist eine schwache Reaktion.
- Es ist nicht so schlimm wie considered harmful, aber trotzdem leicht toxisch.
  Im Kern scheint es darum zu gehen, irgendeine beliebige persönliche Vorliebe, etwa A und B in der Reihenfolge zu vertauschen, größer wirken zu lassen, als sie tatsächlich ist.
- Wenn eine Aussage unser Weltbild herausfordert, weckt sie mehr Interesse.
  Für viele Menschen ist das unhöflich, aber die Aufmerksamkeitsökonomie belohnt genau so etwas.
  Edit: Offenbar wurde der Titel in etwas weniger Provokantes geändert.
  Gute Entscheidung.
- Ich bin hergekommen, um etwas Ähnliches zu sagen.
  Ich bin kein großer Fan von Conventional Commits, aber man kann die Leute doch einfach das verwenden lassen, was sie wollen.
- https://knowyourmeme.com/memes/stop-doing-math
  Es gibt ein Meme, das einen Teil der Titel dieses Genres beeinflusst hat.
Seltsam
Der Hauptgrund, diesen Stil von Commit-Messages zu verwenden, ist CI/CD-Automatisierung.
Korrektur: Beim ersten Lesen habe ich diesen Teil im Artikel übersehen, aber er wurde behandelt.
Sorry.
Der Commit-Typ steht ganz vorn, weil er automatisierten Workflows sagt, wie sie den Commit verarbeiten sollen.
Wenn man zum Beispiel CD macht und nur mehrere fix: -Commits hat, wird nur die Patch-Version der semantischen Version erhöht.
Wenn man feat: committet, steigt die Minor-Version, und feat! bedeutet eine Erhöhung der Major-Version.
Auch wenn man für Releases kein CD verwendet, werden semantische Commit-Messages manchmal zur Automatisierung der Changelog-Erstellung genutzt.
Natürlich sollte man in ein Changelog normalerweise nicht einfach die Git-Commit-Messages selbst übernehmen.
Diese Messages richten sich an Entwickler, nicht an Nutzer.
- Der Artikel behandelt diese beiden Punkte ziemlich klar.
  Semantic Versioning geht bei Reverts kaputt, und automatische Changelogs haben die falsche Zielgruppe.
- Ich habe diesen Stil für Versionsinkremente verwendet, und weil das gut funktioniert hat, hätte ich mir gewünscht, dass der Artikel eine praktikable Alternative vorschlägt.
  Inzwischen nutze ich statt SemVer CalVer, also ist es kein Problem mehr, aber die Idee intelligenter automatischer Versionsinkremente gefällt mir.
- Welche Konvention sollte man dann also für Git-Trailer verwenden?
  Selbst wenn im Commit-Titel fix oder feat steht, liefert das Leuten, die die Logs durchsehen, keine nützliche Information.
- Nein, nein.
  Es geht doch darum, Conventional Commits abzuschaffen, damit KI Commits leichter erstellen kann.
Wenn man die Reihenfolge umdreht, wird mein Hauptärgernis tatsächlich gelöst.
Was zum Teufel ist überhaupt ein Feature?
refactor(core): Update webmcp support to use document.modelContext

Wie der Autor sagt, sind die Grenzen zwischen Fix, Verbesserung und allgemeinem Aufräumen unscharf, und jede semantische Änderung in einen separaten Commit zu zerlegen, schafft nur Arbeit ohne Nutzen für irgendwen, weil es am Ende womöglich sowieso wieder gesquasht wird.
Ich sehe Conventional Commits eher als Nebenprodukt des Versuchs, SemVer-Automatisierung umzusetzen, statt als direkte Lösung eines anderen Problems.
Ich finde, Changelogs sollte man ohnehin nicht automatisieren.
Wenn man eine Liste braucht, kann man sich git log ansehen.
Ein Changelog ist eine Gelegenheit, einem breiteren Publikum zu vermitteln, was intern tatsächlich passiert ist.
„Die Leser eines Changelogs sind völlig andere als die Leser eines Commit-Logs.“
„Ein Changelog ist für Nutzer gedacht.“

Dieses Schiff scheint schon abgefahren zu sein.
Die meisten Firmen geben sich mit „Bug Fixes & Performance Improvements“ zufrieden.
Zumindest wenn man sich sowieso keine Mühe gibt, ist ein generiertes Changelog besser als gar keines.
- Die beste Methode, die ich je bei Auto-Update-Software mit wöchentlichen Updates verwendet habe, war, nutzersichtbaren Commits uv: voranzustellen.
  Dann habe ich diese jede Woche gesucht und den Text unverändert übernommen oder leicht überarbeitet.
  Ich habe sie auch im Help-/Release-notes-Menü des Produkts verwendet.
  Es ist schon etwas komisch, mir zu sagen, ich solle aufhören, etwas zu tun, was ich weder tue noch je gehört habe.
  Normalerweise versieht man nur Datenbankschema-Migrationen oder andere wichtige Dinge mit speziellen Präfixen.
- Er verwechselt Changelogs und Release Notes.
  Offenbar kann er auch Commits nicht gut benennen, und vermutlich auch keine Symbole.
  Das ist ein Kompetenzproblem; da er öffentlich darüber jammert, kann man es einfach ignorieren.

GN⁺ 2026-06-06

Lobste.rs-Meinungen

Es freut mich, einen logisch formulierten Einwand gegen conventional commits zu sehen und nicht bloß eine instinktive Abneigung
Ich hatte nie wirklich gründlich darüber nachgedacht, warum ich sie nicht mag, und dachte, vielleicht liegt es daran, dass ich sie mit von LLMs erzeugtem Code verbinde. Vor allem chore: kann ich überhaupt nicht ausstehen; bitte erfindet nicht noch einmal die ungarische Notation. Das hätte von Anfang an nie entstehen sollen
- Besonders chore: gibt es inzwischen nicht einmal mehr im Angular Commit Style Guide; offenbar hat man erkannt, wie vage es ist, und es in build: aufgehen lassen
  Selbst als es noch im Angular-Stil enthalten war, beschrieb chore: recht konkrete Anwendungsfälle, aber in manchen Open-Source-Projekten scheint es eher aus dem Bauch heraus für Arbeiten vergeben zu werden, die sich wortwörtlich wie lästige Pflichten anfühlen
Ich mag conventional commits nicht besonders, aber die vorgeschlagene Alternative scheint zu übersehen, warum scope optional ist
In kleinen Projekten ohne viele klar abgegrenzte Module ist das Konzept eines „scope“ kaum nützlich. Eine hilfreiche Praxis, die beide Seiten auslassen, ist es, im Commit-Titel Issue- oder Ticketnummern unterzubringen; das erleichtert es, zusätzlichen Kontext einer Änderung zu erfassen, und hilft besonders beim Code-Review. Wenn Ticketnummern aber verpflichtend werden, entstehen bei kleinen Änderungen nur nutzlose Tickets, und das mag ich nicht; wenn eine Änderung jedoch einen bestimmten Bug oder eine bestimmte Aufgabe behandelt, sollte sie mit diesem Bug oder dieser Aufgabe verknüpft sein
- Wenn kein scope nötig ist, lässt man ihn einfach weg
  Das ist immer noch besser als ein redundanter Commit-„type“, der schon in der Betreffzeile selbst ersichtlich sein sollte
- Im Idealfall gäbe es überhaupt keinen vorgeschriebenen Commit-Stil, und man würde jeweils die Formulierung verwenden, die zum konkreten Commit passt
  Wenn eine Änderung klar einem Ticket entspricht, nutzt man einen „Ticketnummer“-Commit, andernfalls eine andere Form. Manche Änderungen passen gut zu einem type, aber weniger zu einem scope, und umgekehrt, daher kann man scoped commits und conventional commits auch mischen
Ich würde gern sagen: „Verwendet in Fließtexten keine Monospace-Schrift“
Trotzdem stimme ich der Grundannahme des Textes weitgehend zu
Auch wenn Commit-Messages nicht besonders gut sind, empfehle ich, um ein Gefühl für den Umfang von Änderungen zu bekommen, häufiger git log --name-only oder git log --stat zu verwenden
Wenn man die Dateinamen sieht, hilft das ziemlich dabei zu verstehen, was sich geändert hat, ohne jeden einzelnen Commit öffnen zu müssen
Eine Vorgehensweise, die mir wirklich gefällt, ist es, den conventional-commit-Stil für PR-Titel zu erzwingen
PR-Titel können auch nach dem Merge noch von Maintainern geändert werden, man muss die Commit-Historie nicht neu schreiben, und zusammen mit Tools wie release-drafter lassen sich aussagekräftige Changelogs in GitHub-Releases automatisieren. Damit bekommt man genau die passende Granularität für die vom Autor genannten Stakeholder, also eine Trennung nach Features, Fixes und Breaking Changes, und zugleich wird für den nächsten GitHub-Release-Entwurf eine sinnvolle semver-Version automatisch abgeleitet
Der Einwand des Autors, dass eine Komponente wie parse-lib nicht optional sein sollte, ist richtig, und ich stimme auch zu, dass das Erzwingen von conventional commits neue Beiträge abschrecken kann. Aber die Alternativen sind auch nicht wirklich besser
Trotzdem vermittelt ein Breaking-Change-Bezeichner wie fix!(parse-lib): Don't leave sparse holes when parsing JSON arrays ziemlich viele Informationen. Es ist ein Bugfix für eine bestimmte Komponente, mit einem unvermeidlichen Breaking Change als Folge, und trägt eine Bedeutung wie eine semver-Erhöhung. So etwas kann man gut im PR-Titel verwenden
Ich gebe zu, dass ich conventional commits als Methode zur Förderung von Commit-Disziplin zu sehr verinnerlicht habe, und am Ende wurde es einfach zur Gewohnheit
Inzwischen empfinde ich sie oft als einschränkend und willkürlich. In manchen Projekten weiß ich nicht einmal, ob das dort tatsächlich Konvention ist, und ich bin eher näher an Linux-/Go-/Node-Stilen gelandet; in Monorepos mit vielen unterschiedlichen Setups fühlte es sich natürlicher an, [service]: [what changed] zu schreiben, statt einen type zu erzwingen. Künftig möchte ich bei meinem persönlichen Commit-Stil mehr experimentieren und mich eher daran orientieren, was nützlich erscheint, statt mich an eine strikte Konvention anzupassen; scoped commits wirken dabei wie ein guter Ausgangspunkt
chore(lobsters): add my 2 cents on conventionals commits [JIRA-69420]
Ich stimme fast vollständig zu, sehe aber einen Punkt anders: den Teil über „revisionistische Aufzeichnungen, die den Beitragenden gezeigt werden und die Zuverlässigkeit der Geschichte verringern, die das Commit-Log erzählt“. Der Autor scheint hauptsächlich von öffentlichen Branches zu sprechen, und für öffentliche Branches ist das ein vernünftiger Rat. Auf private Branches sollte das aber nicht angewendet werden. Es reicht, die Historie so zu gestalten, dass die Person, die die endgültige Änderung prüft – also ein Maintainer oder ich in zehn Jahren – sie leicht verstehen kann; man muss keinen inkonsistenten Gedankengang oder, schlimmer noch, eine Ansammlung von address review-Commits zurücklassen
Die Antwort auf „Warum ist scope optional?“ lautet bei kleinen Projekten schlicht, dass das gesamte Projekt der scope ist
Ich stimme zu, dass der „type“ eines Commits nicht besonders nützlich ist, aber ich bin mir auch nicht sicher, ob es zwischen scoped commits und conventional commits überhaupt einen großen Unterschied gibt. Scoped ist im Grunde nur conventional ohne „type“, und eine Unterscheidung zwischen fix, feat, refactor und chore ist durchaus in Ordnung
Wenn ohnehin alle einfach die Standardwerte von commitlint übernehmen, müsste man die Leute dann nicht einfach dazu bringen, besser damit umzugehen?