Konventionelle Commits-Klassifizierung ⇐ Artikelentwürfe

[Anonymous]

„Conventional Commits Specification“ (CCS) ist die Spezifikation, die die Kategorisierung von Commits (Versionskontrolle) in Versionskontrollsystemen formalisiert. Dieses Klassifizierungssystem unterscheidet Codeänderungen nach ihrem Zweck – etwa Funktionen, Fehlerbehebungen oder Dokumentationsaktualisierungen –, um automatisierte Prozesse wie Changelog|Änderungsprotokollgenerierung und semantische Versionierung|semantische Versionierung zu ermöglichen.
== Hintergrund ==
Die moderne verteilte Softwareentwicklung ist stark auf Commit-Nachrichten angewiesen, um Änderungen zu verfolgen. Während frühe Klassifizierungsrahmen, wie der von Swanson 1976 vorgeschlagene, die Wartung in drei Typen kategorisierte (perfektiv, adaptiv und korrigierend), hat sich die moderne Entwicklung hin zu feinkörnigeren Taxonomien verlagert.
Die Conventional Commits Specification (CCS) ist ein weit verbreiteter Standard, der verlangt, dass Commit-Nachrichten einem bestimmten Format folgen:

[optionaler Bereich]:
[optionaler Körper]
[optionale Fußzeile(n)]

Das Obligatorische
== Klassifizierungstypen ==
Untersuchungen zur CCS-Nutzung haben zehn Hauptkategorien identifiziert, die zur Klassifizierung von Commits verwendet werden. Um Mehrdeutigkeiten zu beseitigen, die in früheren Definitionen (z. B. denen aus dem Angular-(Web-Framework)|Angular-Projekt) festgestellt wurden, wurden die folgenden Definitionen vorgeschlagen, um Überschneidungen zu minimieren:
* „Feature (feat):“ Änderungen, die neue Funktionen in die Codebasis einführen. Dies umfasst sowohl benutzerorientierte als auch entwicklerorientierte Funktionen.
* „Fix (Fix):“ Änderungen, die Fehler oder Fehler beheben.
* „Leistung (Leistung):“ Modifikationen, die speziell auf die Verbesserung der Leistung (z. B. Ausführungsgeschwindigkeit, Speichernutzung) abzielen, ohne das Verhalten zu ändern.
* „Stil (Stil):“ Änderungen, die die Lesbarkeit des Codes verbessern, ohne die Bedeutung zu ändern (z. B. Formatierung, Einrückung, Variablenbenennung).
* ''Refactor (Refaktor):'' Restrukturierung des Codes zur Verbesserung der Wartbarkeit, ohne das externe Verhalten zu ändern. Diese Kategorie schließt ausdrücklich Änderungen aus, die streng unter „Stil“ oder „Perf“ fallen.
* „Dokumentation (Dokumente):“ Änderungen an Dokumentation oder Textdateien (z. B. Kommentare, READMEs).
* ''Test (test):'' Testdateien hinzufügen oder aktualisieren.
* „Continuous Integration (ci):“ Änderungen an CI-Konfigurationsdateien und Skripten (z. B. GitHub Actions, Travis CI).
* „Build (Build):“ Änderungen, die das Build-System oder externe Abhängigkeiten (z. B. Gradle, Maven) betreffen.
* ''Chore (lästige Pflicht):'' Verschiedene Aufgaben, die nicht in die anderen Kategorien passen.

Diese Typen kategorisieren Commits basierend auf zwei Dimensionen: „Zweck“ (Motivation, z. B. Refactoring) und „Objekt“ (was sich geändert hat, z. B. Tests). Bei Überschneidungen steht typischerweise der Zweck im Vordergrund; Beispielsweise wird die Umgestaltung einer Testdatei als „Refaktor“ und nicht als „Test“ klassifiziert.
== Annahme und Nutzung ==
Die Einführung von CCS hat zu einem stetigen Wachstum der Open-Source-Community geführt. Eine Studie aus dem Jahr 2025, in der über 3.000 Top-GitHub-Projekte analysiert wurden, ergab, dass die Zahl der Projekte, die CCS offiziell einführen, seit 2017 stetig gestiegen ist. * „Dokumenterklärung:“ Explizite Angabe der Konvention in beitragenden Richtlinien.
* „Integrierte Automatisierung:“ Mit Tools wie
Selbst in Projekten, die die Spezifikation nicht offiziell vorschreiben, hielten sich etwa 10 % der von Entwicklern im Jahr 2023 eingereichten Commits freiwillig an das Format, was auf seine wachsende Beliebtheit bei einzelnen Entwicklern hinweist.
== Herausforderungen ==
Bei der manuellen Klassifizierung von Commits nach CCS stehen Entwickler vor mehreren Herausforderungen. Eine qualitative Analyse der Entwicklerdiskussionen auf GitHub und Stack Overflow identifizierte vier Hauptprobleme: # „Typverwirrung“: Die häufigste Herausforderung (ca. 58 % der Probleme), bei der Entwickler nicht sicher sind, welcher Typ zutrifft. Es besteht häufige Verwirrung zwischen # ''Type Aliases:'' Anfragen zur Verwendung von Synonymen, z. B. „patch“ anstelle von „fix“.
# ''Typen ändern:'' Anfragen zum Hinzufügen neuer Typen (z. B. „Sicherheit“) oder zum Entfernen vorhandener Typen.
# „Mangel an Definitionen:“ Erfordert eine umfassende, standardisierte Liste von Definitionen, da die offizielle Spezifikation häufig auf die Richtlinien von Angular zurückgreift, die einige Entwickler für mehrdeutig halten.
== Automatisierte Klassifizierung ==
Angesichts der Komplexität und Granularität der zehn CCS-Kategorien wurde eine automatisierte Klassifizierung untersucht, um Entwickler zu unterstützen. Während traditionelle Ansätze mit BERT (Sprachmodell)|BERT für die Klassifizierung in drei Kategorien (adaptiv, korrigierend, perfektiv) erfolgreich waren, haben sie mit den feineren Unterscheidungen von CCS Schwierigkeiten.
Jüngste Ansätze, die Large Language Models (LLMs), insbesondere fein abgestimmte Modelle wie Llama (Sprachmodell) | CodeLlama, verwenden, haben eine überlegene Leistung gezeigt. Ein fein abgestimmtes CodeLlama-Modell erreichte einen Makro-F1-Score von etwa 76 % und übertraf damit sowohl BERT als auch GPT-4 bei der korrekten Klassifizierung von Commits in die zehn CCS-Typen.

== Quellen ==
*
Softwareentwicklung
Versionskontrolle