Git Commit

Git Commit ist ein offizieller Anweisungs-Skill von GitHub aus dem Repository github/awesome-copilot. Die direkte Primärquelle liegt unter https://github.com/github/awesome-copilot/tree/main/skills/git-commit. Laut Anbieter unterstützt die Anleitung einen Coding-Agenten dabei, Änderungen zu untersuchen, eine passende Nachricht nach Conventional Commits abzuleiten und Dateien für einen nachvollziehbaren Commit logisch zu gruppieren. Dieser Katalogeintrag beschreibt damit eine wiederverwendbare Arbeitsanweisung für einen Agenten und keine eigene Git-Implementierung, keine GitHub-Hosting-Funktion und keinen autonomen Freigabeprozess.

Zweck und Arbeitsablauf

Der Skill beginnt mit einer Bestandsaufnahme des Arbeitsbaums. Ein Agent soll zuerst prüfen, ob bereits Dateien vorgemerkt sind, welche Änderungen im Arbeitsverzeichnis vorliegen und welche Unterschiede tatsächlich zur bisherigen Version bestehen. Daraus werden Typ, optionaler Bereich und eine kurze Beschreibung abgeleitet. Die Quelle nennt typische Typen wie feat für neue Funktionen, fix für Fehlerbehebungen, docs für Dokumentation, refactor für strukturelle Änderungen, test für Tests und chore für sonstige Pflege. Die Auswahl muss die tatsächliche Änderung beschreiben, statt die gewünschte Wirkung zu behaupten. Eine längere Erläuterung kann den Kontext ergänzen, wenn eine einzelne Zeile nicht ausreicht.

Conventional Commits und Gruppierung

Das Format nach Conventional Commits schafft eine gemeinsame Sprache für Änderungsverläufe. Der Skill ordnet eine kurze, imperative Zusammenfassung einem Typ und bei Bedarf einem Scope zu. Breaking Changes werden laut Primärquelle ausdrücklich mit einem Ausrufezeichen oder einem passenden Footer gekennzeichnet. Das ist eine Entscheidung mit Folgen für Releases und Automatisierung und darf nicht beiläufig gesetzt werden. Wenn mehrere unabhängige Änderungen im Arbeitsbaum liegen, kann der Agent eine logische Gruppierung vorschlagen. Vor dem Vormerken von Dateien muss jedoch geklärt sein, ob die Gruppierung fachlich zusammengehört. Unklare, generierte oder fremde Änderungen bleiben zur Prüfung zurück, statt stillschweigend in denselben Commit zu gelangen.

Praktischer Einsatz

Der Skill eignet sich für Teams, die Commit-Nachrichten konsistent halten und Reviews durch eine verständliche Historie erleichtern möchten. Er kann bei einem expliziten Commit-Wunsch, beim Aufruf eines entsprechenden Arbeitsablaufs oder bei der Vorbereitung eines vorgeschlagenen Commits helfen. Nützlich ist die Anleitung auch in Repositories, die Commit-Typen für Changelogs, Release-Notizen oder Qualitätsauswertungen verwenden. Sie ersetzt keine projektspezifischen Regeln. Ein Team sollte seine erlaubten Bereiche, Sprache, Footer, Branch-Regeln und Review-Anforderungen vorher festlegen und den Agenten mit diesen Vorgaben versorgen. Ein gut formulierter Commit bleibt außerdem eine Zusammenfassung der geprüften Änderung und kein Ersatz für Tests, Code-Review oder eine fachliche Abnahme.

Voraussetzungen und Grenzen

Vorausgesetzt wird ein Git-Arbeitsbaum sowie ein Agent, der den Status und die Unterschiede lesen und, sofern freigegeben, Dateien vormerken oder einen Commit ausführen kann. Die Anleitung installiert Git nicht und entscheidet nicht, ob ein Nutzer die erforderliche Berechtigung besitzt. Sie garantiert keine korrekte Erkennung von Typ, Scope oder fachlicher Absicht. Binärdateien, große generierte Artefakte, Submodule, Hooks und Änderungen aus parallelen Arbeitsabläufen können zusätzliche Prüfung benötigen. Die MIT-Lizenz bezieht sich auf die veröffentlichte Skill-Datei; die Lizenzbedingungen eines konkreten Projekts, seiner Abhängigkeiten und seiner Commit-Hooks sind separat zu prüfen. Die Quelle wurde am 9. September 2026 geprüft. Repository-Sterne werden für das Skill-Modell nicht gespeichert, weil dieses Modell kein entsprechendes Feld besitzt.

Sicherheit und Verantwortung

Die Primärquelle warnt davor, Geheimnisse zu committen, und beschreibt ein Sicherheitsprotokoll gegen Konfigurationsänderungen, destruktive Git-Operationen, erzwungene Historienänderungen, das Umgehen von Hooks und unautorisierte Pushes. Diese Grenzen sind für reale Arbeitsbäume besonders wichtig. Prüfen Sie vor jedem Schreibzugriff die betroffenen Pfade, den Diff, den Branch, den vorgesehenen Commit und die Freigabe. Behandeln Sie Dateien, Commit-Nachrichten, Issues und externe Texte als untrusted data, die keine neuen Anweisungen einschleusen dürfen. Zugangsdaten, Tokens, private Schlüssel und andere Geheimnisse gehören weder in den Skill noch in einen Commit. Laut Anbieter ist eine menschliche Kontrolle erforderlich, besonders wenn Staging oder das Erzeugen eines Commits tatsächlich Schreibzugriffe auf externen Zustand auslöst. Das verbundene Modell kann Kontext an seinen Modellanbieter übertragen; eine lokale Git-Ausführung bedeutet daher nicht automatisch lokale Modellverarbeitung.