Atomic Git Commit erstellen

Minimaler Git Commit

Ziel

Erstellen Sie einen oder mehrere atomare Commits für die aktuelle Agentenaufgabe. Jede generierte Commit-Nachricht folgt Conventional Commits. Halten Sie gewöhnliche Anweisungen low-context; reservieren Sie die vollständige Diff-Analyse für eine explizite Full-Mode-Anforderung.

Modusauswahl

• Verwenden Sie standardmäßig den Quick Mode.
• Verwenden Sie den Full Mode nur, wenn der Benutzer full sagt, bittet, das vollständige Diff zu scannen oder zu analysieren, oder explizit darum bittet, jede Änderung zu überprüfen.
• Stufen Sie den Quick Mode nicht stillschweigend auf den Full Mode hoch. Wenn dem Quick Mode nicht genügend Informationen vorliegen, fragen Sie nach einer Zusammenfassung der Änderungen oder bitten Sie den Benutzer, den Full Mode zu wählen.

Quick Mode

Verwenden Sie zuerst die explizite Zusammenfassung des Agenten zur aktuellen Aufgabe. Wenn nötig, überprüfen Sie nur:

git status --short
git diff --stat

Lesen Sie nicht das vollständige Diff oder die Historie. Raten Sie nicht über Änderungen, die in der Zusammenfassung nicht erwähnt werden. Gruppieren Sie die genannten Änderungen in atomare Commits und generieren Sie deren Nachrichten. Wenn der Benutzer explizit bittet, zu committen, zeigen Sie die geplanten Dateien/Nachrichten an, bevor Sie den Index ändern oder Commits erstellen, wenn die Dateigrenze unklar ist.

Full Mode

Lesen Sie das vollständige relevante Arbeitsverzeichnis und die gestagten Diffs, überprüfen Sie alle geänderten Dateien und lesen Sie die Conventional Commits Referenz. Überprüfen Sie auf ausgelassene Features, Tests, Dokumentation, Konfiguration, nicht zusammenhängende Dateien, sensible Dateien, generierte Dateien und unabhängige logische Änderungen. Bestätigen Sie, dass generierte Dateien zur Versionierung gehören: Behalten Sie projektnotwendige Ausgaben wie Lockfiles oder Migrationen und schließen Sie Build-Artefakte und lokale Ausgaben aus. Teilen Sie unabhängige Features, Bugfixes, Refactorings und reine Formatierungsänderungen in atomare Commits auf; halten Sie Änderungen zusammen, wenn sie eng gekoppelt sind und nicht unabhängig getestet oder rückgängig gemacht werden können. Führen Sie für die geänderten Dateien relevante Überprüfungen mit vorhandenen Projektbefehlen durch. Führen Sie nicht standardmäßig die vollständige Test-, Lint- und Typprüfungssuite aus; verwenden Sie Überprüfungen, die bereits während der Aufgabe durchgeführt wurden, erneut und erweitern Sie die Überprüfung nur auf Anfrage oder wenn es die Änderungen erfordern. Überprüfen Sie die Historie nicht, es sei denn, es wird explizit darum gebeten.

Führen Sie vor git add oder git commit keine Benutzeränderungen aus, die außerhalb der aktuellen Aufgabe liegen. Führen Sie diese Mutationen nur aus, wenn der Benutzer explizit darum bittet, zu committen. Führen Sie im Rahmen dieser Fähigkeit niemals einen Push durch.

Commit-Regeln

Verwenden Sie diese Form:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

• Verwenden Sie feat für ein neues Feature und fix für eine Bugbehebung.
• Bevorzugen Sie die Projekttypen docs, style, refactor, perf, test, build, ci, chore und revert, wenn sie die Änderung genau beschreiben.
• Verwenden Sie einen Substantiv-Scope in Klammern nur dann, wenn er nützlichen Kontext hinzufügt.
• Kennzeichnen Sie Breaking Changes mit ! vor dem Doppelpunkt oder einem großgeschriebenen BREAKING CHANGE: Footer.
• Halten Sie die Beschreibung prägnant, im Präsens, imperativ und vorzugsweise unter 72 Zeichen.
• Ein Commit repräsentiert eine logische Änderung. Teilen Sie unabhängige Features, Fixes, Tests, Dokumentation und Refactorings wann immer möglich auf.
• fix entspricht SemVer PATCH, feat MINOR und jede Breaking Change MAJOR; ändern Sie keine Versionsdateien, es sei denn, dies wird separat angefordert.

Sicherheit und Bestätigung

• Verwenden Sie standardmäßig niemals git add .; fügen Sie nur Dateien hinzu, die zur aktuellen Aufgabe gehören.
• Committen Sie niemals .env, Anmeldeinformationen, Tokens, private Schlüssel oder andere Geheimnisse.
• Überprüfen Sie im Full Mode den gestagten Inhalt auf Geheimnisse und bestätigen Sie, dass generierte oder Build-Dateien vom Projekt erwartet werden, bevor Sie sie einbeziehen.
• Ändern Sie niemals die Git-Konfiguration, überspringen Sie keine Hooks, führen Sie keinen Force-Push durch und ändern Sie keinen vorhandenen Commit, es sei denn, der Benutzer fordert diese genaue Aktion explizit an.
• Mischen Sie nicht bereits vorhandene Benutzeränderungen mit den Änderungen des Agenten.
• Halten Sie an und fragen Sie nach, wenn die Aufgabenabgrenzung, Dateibesitzer, logische Aufteilung oder der Status sensibler Dateien unklar ist.
• Das Erstellen einer Nachricht ist keine Berechtigung zum Erstellen eines Commits; fordern Sie eine explizite Commit-Anforderung an, bevor Sie git add oder git commit ausführen.

Referenz

Lesen Sie references/conventional-commits.md im Full Mode oder wenn ein Typ, Footer, Breaking Change, Revert, SemVer oder eine FAQ-Frage eine detaillierte Behandlung benötigt.