Gut formulierte Commit-Messages sind entscheidend für die Lesbarkeit und Nachvollziehbarkeit eines Softwareprojekts. Sie dokumentieren Änderungen, unterstützen Code-Reviews und helfen bei der Fehlersuche. Dennoch fallen sie im Alltag oft zu kurz aus oder wirken uneinheitlich. Genau hier setzt dieser Beitrag an: Er zeigt, wie sich Commit Messages git diff mithilfe Künstlicher Intelligenz automatisch erzeugen lassen – strukturiert, konsistent und in einem einheitlichen Format. Zum Einsatz kommen dabei wahlweise die Cloud-API von OpenAI oder ein lokal installiertes Modell wie Mixtral über Ollama.
Hinweis: Dieser Artikel wurde mithilfe von ChatGPT 5 erstellt und redaktionell überarbeitet.
Motivation und Grundidee
Commit-Messages sind das Gedächtnis eines Softwareprojekts. Sie dokumentieren nicht nur, welche Änderungen am Code vorgenommen wurden, sondern helfen auch bei Code-Reviews, der Fehlersuche und der langfristigen Nachvollziehbarkeit. In der Praxis zeigt sich jedoch, dass viele Commit-Texte zu knapp, unpräzise oder uneinheitlich formuliert sind. Das liegt oft daran, dass das Schreiben einer guten Commit-Message Zeit kostet und ein gewisses Maß an Disziplin erfordert – Ressourcen, die im hektischen Entwicklungsalltag knapp sind.
Die hier vorgestellte Lösung setzt auf Künstliche Intelligenz, um diesen Engpass zu überwinden. Statt jede Commit-Message von Hand zu formulieren, analysiert ein KI-Modell automatisch den aktuellen Code-Diff aus git diff und erstellt daraus eine strukturierte, verständliche und stilistisch konsistente Beschreibung. Dabei werden nicht nur die Änderungen zusammengefasst, sondern auch ein prägnanter Titel, ein kurzer Kontext und eine Übersicht der betroffenen Dateien generiert. Die KI kann sowohl über eine Cloud-API wie OpenAI als auch lokal mit einem Modell wie Mixtral über Ollama betrieben werden. Beide Ansätze liefern am Ende ein einheitliches Ausgabeformat, das sich nahtlos in den Entwicklungsworkflow integrieren lässt.
Der gesamte Prozess lässt sich in wenigen Schritten zusammenfassen:
-
Diff erfassen – z. B. nur gestagte Änderungen:
git diff --cached. - Prompt erstellen – Format & Sprache klar definieren.
- Modell ansprechen – Cloud‑API oder lokal.
-
Ergebnis abspeichern – etwa
commit_message.txt. - Manuell prüfen – Inhalt und Formulierung kontrollieren, ggf. anpassen (siehe Hinweis).
-
Schnell committen – per Symlink mit
git commit -F.
Zwei Umsetzungsvarianten
Für die automatische Erstellung von Commit-Messages aus git diff stehen grundsätzlich zwei technische Ansätze zur Verfügung: der Zugriff auf ein Cloud-basiertes KI-Modell und die Ausführung eines lokal installierten Modells. Beide Varianten haben ihre eigenen Vor- und Nachteile und lassen sich je nach Anforderungen und Rahmenbedingungen flexibel einsetzen.
Cloud-API
Die erste Möglichkeit ist der Einsatz einer Cloud-API wie die von OpenAI. Hier profitieren Entwickler von einer hohen Modellqualität – beispielsweise mit GPT-4.1-mini oder GPT-5 – ohne dass eine eigene Modellinstallation nötig wäre. Der Einstieg ist unkompliziert: Nach dem Erfassen des Diffs wird ein Prompt mit klaren Anweisungen im JSON-Format erstellt und per curl-Befehl an die API gesendet. Das Ergebnis lässt sich anschließend mit jq extrahieren und in einer Datei ablegen, die über die Umgebungsvariable PAYLOAD referenziert wird. Der API-Aufruf erfolgt dann wie folgt:
# API-Aufruf mit OpenAI
curl -s https://api.openai.com/v1/chat/completions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d @"${PAYLOAD}" \
> "${RESPONSE}"
Hierbei steht OPENAI_API_KEY für den persönlichen API-Schlüssel, PAYLOAD für die zuvor erzeugte JSON-Datei mit dem Prompt, und RESPONSE für die Zieldatei, in der die Antwort der API gespeichert wird. Das Ergebnis kann anschließend mit jq extrahiert und als Commit-Message-Datei abgelegt werden. Diese Variante ist schnell einsatzbereit, erfordert jedoch eine Internetverbindung, verursacht laufende Kosten pro Anfrage und überträgt den Diff an einen externen Dienst, was datenschutzrechtlich zu beachten ist.
Lokale Ausführung (Mixtral mit Ollama)
Wer maximale Datenkontrolle benötigt oder komplett offline arbeiten möchte, kann ein Modell wie Mixtral lokal ausführen. Der Prompt wird hier direkt über die Standardeingabe (stdin) an Ollama übergeben, da das --prompt-Flag beim run-Befehl nicht unterstützt wird:
# Mixtral aufrufen und Ausgabe in OUTFILE schreiben
# Prompt über stdin geben, da --prompt-Flag bei 'run' nicht unterstützt wird
echo -e "$FULL_PROMPT" | ollama run mixtral:8x7b > "$OUTFILE"
In diesem Beispiel enthält FULL_PROMPT den vollständigen, formatieren Prompt-Text, während OUTFILE die Zieldatei ist, in der die erzeugte Commit-Message gespeichert wird. Die Ausführung erfordert eine leistungsfähige Hardware und den vorherigen Download des Modells, bietet dafür aber vollständige Unabhängigkeit von externen Diensten.
Beide Wege führen zum gleichen Ziel: einer automatisch generierten Commit-Message in einem klar definierten Format. Welche Variante sich anbietet, hängt davon ab, ob der Schwerpunkt auf maximaler Modellqualität und geringem Setup-Aufwand oder auf vollständiger lokaler Datenverarbeitung und Unabhängigkeit von externen Diensten liegt.
Einheitliches Ausgabeformat
Ob die Commit-Message über die OpenAI-API oder lokal mit Mixtral erzeugt wird, das Ergebnis folgt stets einem fest definierten ASCII-Format. Dieses besteht aus einem prägnanten Titel, einer kompakten Kontextbeschreibung sowie einer Liste der geänderten Dateien mit den jeweiligen Änderungsarten ([Add], [Mod], [Del], [Refactor], [Clean]). Durch die konsequente Anwendung dieser Struktur bleibt die Commit-Historie klar und konsistent.
Die Vorgaben für dieses Format werden im System-Prompt hinterlegt. Er definiert das Layout und weist das Modell an, ausschließlich in der festgelegten Form zu antworten. Dieses Prinzip ist unabhängig von der gewählten Implementierungsvariante.
# System-Prompt als Here-Doc mit Format-Skelett
read -r -d '' SYSTEM_PROMPT <<'EOF'
Du bist ein Git-Experte und Commit-Message-Generator.
Antworte auf **Deutsch** und erzeuge **ausschließlich** eine Commit-Message im exakt folgenden ASCII-Format:
===========================================================
Commit: <Kurztitel des Commits – funktional und prägnant>
===========================================================
CONTEXT:
---------
- <Kompakte Aufzählung der übergeordneten Änderungen>
- <Was wurde verbessert, abstrahiert, entfernt oder robuster gemacht?>
------------------------------------------------------------
FILE: <Pfad/zur/Datei.cpp>
METHOD/CLASS: <Name> (optional)
------------------------------------------------------------
- [Add] ...
- [Mod] ...
- [Del] ...
- [Refactor] ...
- [Clean] ...
EOF
Das Format wird künftig um das zusätzliche Flag [FIX] (für Bugfixes) erweitert. Dieses Kennzeichen befindet sich derzeit in der Test- bzw. Entwicklungsphase und wird nach erfolgreicher Erprobung in das reguläre Ausgabeformat übernommen.
OpenAI-Variante
Bei Nutzung der Cloud-API von OpenAI werden der System-Prompt und der git diff in eine JSON-Struktur eingebettet. jq übernimmt dabei das korrekte Escaping sämtlicher Zeichen. Anschließend wird die JSON-Datei als Payload an die API gesendet:
jq -n \
--arg model "gpt-4.1-mini" \
--arg system "$SYSTEM_PROMPT" \
--arg user "Analysiere bitte diesen Git-Diff und gib die Commit-Message **nur** im oben vorgegebenen ASCII-Format zurück.\n\nDiff:\n$DIFF" \
--argjson max 500 \
--argjson temp 0.2 \
'{
model: $model,
messages: [
{ role:"system", content: $system },
{ role:"user", content: $user }
],
max_tokens: $max,
temperature: $temp
}' > "${PAYLOAD}"
PAYLOAD steht für die temporäre JSON-Datei mit dem Prompt. OPENAI_API_KEY enthält den persönlichen API-Schlüssel. RESPONSE gibt die Datei an, in der das Skript die generierte Commit-Message speichert.
Mixtral/Ollama-Variante
Für die lokale Ausführung mit Mixtral entfällt die JSON-Erzeugung. Stattdessen wird der vollständige Prompt über die Standardeingabe an Ollama übergeben, das Ergebnis direkt in eine Datei geschrieben:
# Prompt über stdin geben, da --prompt-Flag nicht unterstützt wird
echo -e "$FULL_PROMPT" | ollama run mixtral:8x7b > "$OUTFILE"
In FULL_PROMPT befindet sich der System-Prompt zusammen mit dem aktuellen git diff. OUTFILE gibt die Datei an, in der die Commit-Message abgelegt wird. Dieser Ansatz arbeitet vollständig lokal und erfordert keine Übertragung von Daten an externe Dienste.
Das vollständige, kommentierte Skript für beide Varianten steht im GitHub-Repository zur Verfügung:
GWR Commit-Message-Generator auf GitHub.
Automatisierung, Komfortfunktionen und Projektstruktur
Die Skripte sind so konzipiert, dass sie sich nahtlos in bestehende Git-Workflows einfügen und den manuellen Aufwand minimieren. Nach der Generierung wird die Commit-Message in einer Datei gespeichert, auf die ein symbolischer Link verweist. Diese Datei sollte immer auf Inhalt, Sprache und Vollständigkeit geprüft und bei Bedarf ergänzt oder angepasst werden, bevor sie übernommen wird. Erst danach kann sie – falls gewünscht – direkt in den Commit übernommen werden:
git commit -F latest-Commit-MSG-openai.txt
# oder
git commit -F latest-Commit-MSG-mixtral.txt
Dieser direkte Commit-Befehl ist als Komfortfunktion gedacht und setzt voraus, dass der Inhalt bereits manuell kontrolliert wurde.
Zusätzlich sorgt ein separates Hilfsskript für die automatische Bereinigung älterer Log-Dateien. Über eine einfache Konfiguration lässt sich festlegen, wie viele Tage die Einträge vorgehalten werden. So bleiben die Log-Verzeichnisse übersichtlich, ohne dass der Nutzer manuell eingreifen muss.
Die hier dargestellte Struktur stammt aus dem aktuellen Entwicklungs- und Testverzeichnis der Skripte – insofern besteht ein gewisser „Selbstbezug“. In der praktischen Nutzung liegen die ausführbaren Skripte in einem bekannten Verzeichnis, das im $PATH eingebunden ist (z. B. ~/bin), und werden direkt im jeweiligen Arbeitsverzeichnis ausgeführt. Die hier gezeigte Anordnung mit getrennten Log-Verzeichnissen pro Variante (openai oder mixtral) sowie dem Symlink latest auf den jüngsten Lauf bleibt dabei unverändert. Sie erleichtert sowohl die manuelle Durchsicht älterer Ergebnisse als auch die Integration in automatisierte Prozesse wie Continuous-Integration-Pipelines.
Beispielhaft zeigt die folgende Übersicht den Aufbau des Entwicklungsverzeichnisses:
.
├── cleanup_logs.sh
├── generate_commit_msg.sh
├── logs
│ ├── mixtral
│ │ ├── 2025-08-12_16-05-45
│ │ ├── 2025-08-12_16-06-13
│ │ ├── 2025-08-12_16-19-56
│ │ ├── 2025-08-12_16-40-59
│ │ └── latest -> 2025-08-12_16-40-59
│ └── openai
│ ├── 2025-08-12_15-30-53
│ ├── 2025-08-12_15-40-08
│ ├── 2025-08-12_15-50-10
│ ├── 2025-08-12_16-24-05
│ │ ├── commit_message.txt
│ │ ├── payload.json
│ │ └── response.json
│ └── latest -> 2025-08-12_16-24-05
├── mixtral-commit.sh
└── README.md
Die Trennung der Logs nach Variante stellt sicher, dass Ergebnisse aus Cloud- und Lokalausführung jederzeit eindeutig zugeordnet werden können.
Wichtiger Hinweis: Eine ungeprüfte Übernahme der generierten Commit-Messages wird nicht empfohlen. Die automatisch erzeugten Commit-Messages dienen als Unterstützung, ersetzen aber nicht die fachliche Prüfung. Vor jedem Commit sollte der Text inhaltlich und sprachlich kontrolliert und bei Bedarf angepasst werden. git diff kann z. B. Änderungen nicht immer korrekt Methoden oder Funktionen zuordnen, und auch das KI-Modell ist nicht unfehlbar – eine manuelle Sichtprüfung bleibt daher unerlässlich.
Fazit
Die automatisierte Erzeugung von Commit-Messages aus git diff mit Hilfe von KI spart Zeit, sorgt für konsistente Formate und unterstützt eine klare Projekthistorie. Sowohl die Cloud-Variante über die OpenAI-API als auch die lokale Ausführung mit Mixtral/Ollama bieten leistungsfähige Ansätze, die sich je nach Anforderungen flexibel einsetzen lassen. Durch die einheitliche Formatvorgabe entsteht ein strukturiertes Ergebnis, das sich unmittelbar in bestehende Workflows einbinden lässt.
Gleichzeitig gilt: Die generierten Texte sind eine Unterstützung, aber kein Ersatz für die fachliche Beurteilung durch den Entwickler. Vor jedem Commit sollte der Inhalt geprüft und bei Bedarf angepasst werden – nicht nur um Formulierungen zu optimieren, sondern auch, um mögliche Fehlzuordnungen zu vermeiden, die durch git diff oder die Modellinterpretation entstehen können.
Ein ähnlicher Ansatz ist zudem für die automatisierte Überprüfung von Log-Dateien eines Jenkins-Laufs geplant. Hierbei könnten KI-Modelle Abweichungen oder Muster identifizieren, die in herkömmlichen Prüfprozessen leicht übersehen werden.