Commit in Batches

In Batches committen

Teilen Sie ungestellte Arbeit in logische Commits auf. Jeder Commit sollte für sich allein überprüfbar sein und alle Dateien enthalten, die für diesen Ausschnitt erforderlich sind, damit er sinnvoll ist.

Sicherheit (immer)

• Aktualisieren Sie niemals die Git-Konfiguration.
• Führen Sie niemals git push --force, git reset --hard oder andere destruktive Git-Befehle aus, es sei denn, der Benutzer fordert dies ausdrücklich.
• Umgehen Sie niemals Hooks (--no-verify usw.), es sei denn, der Benutzer fordert dies ausdrücklich.
• Stagen Sie niemals Geheimnisse (.env, Anmeldedaten, Schlüssel). Warnen Sie davor und schließen Sie sie aus.
• Verwenden Sie git commit --amend nur, wenn die Benutzerregeln für das Ändern vollständig erfüllt sind.
• Wenn ein Commit-Hook fehlschlägt, beheben Sie das Problem und erstellen Sie einen neuen Commit; ändern Sie keinen fehlgeschlagenen Commit.
• Fügen Sie Co-authored-by: Cursor nicht zu Commit-Nachrichten hinzu.

1. Prüfen

Führen Sie nach Möglichkeit parallel aus:

• git status
• git diff und git diff --staged
• git log -5 --oneline für den Nachrichtenstil
• git remote -v und Branch-Tracking (git status -sb)

Wenn es nichts zu committen gibt, stoppen Sie und teilen Sie dies mit.

2. Batches planen

Gruppieren Sie Änderungen nach Zweck, nicht nur nach Dateityp. Beispiele:

• Eine Funktion oder ein benutzerseitiges Verhalten + zugehörige Tests und Dokumentation
• Eine Fehlerbehebung + nur die Dateien, die sie beheben
• Refactoring, das eigenständig ist, ohne unzusammenhängende Funktionen zu mischen
• Aufgabe oder Tooling, das auf einen Bereich beschränkt ist (Abhängigkeiten, CI, Konfiguration)

Regeln:

• Mischen Sie keine unzusammenhängenden Funktionen in einem Commit.
• Fügen Sie Begleitdateien in denselben Batch ein (z. B. Schema + Entität + Migration + Aufrufstellen für eine Änderung).
• Wenn eine Datei zwei Belange betrifft, bevorzugen Sie den dominanten Batch oder erwähnen Sie den Kompromiss vor dem Committen.
• Listen Sie Batches in der Reihenfolge auf: zuerst Grundlagen (gemeinsame Typen, Konfiguration), dann Funktionen, dann nur Dokumentation, wenn diese von vorherigen Commits abhängt.

Zeigen Sie dem Benutzer einen kurzen Plan an: Batch-Nummer, Dateien oder Pfade, vorgeschlagener konventioneller Commit-Titel. Fahren Sie dann fort, es sei denn, der Benutzer widerspricht.

3. Jeden Batch committen

Führen Sie für jeden Batch nacheinander Folgendes aus:

1. Stagen Sie nur diesen Batch (git add bestimmte Pfade; vermeiden Sie git add -A, es sei denn, der gesamte Baum ist ein Batch).
2. Überprüfen Sie mit git diff --staged, dass nichts Unzusammenhängendes hineingerutscht ist.
3. Schreiben Sie einen konventionellen Commit-Titel (feat, fix, chore, docs, refactor, test usw.), der sich auf das Warum konzentriert.
4. Wenn der Branch-Name eine Issue-ID enthält, fügen Sie #<Issue> an den Titel an (GitLab-Stil).
5. Committen. Verwenden Sie in Windows PowerShell git commit -m 'Titel' (oder mehrere -m für einen kurzen Textkörper). In Bash ist ein HEREDOC für die Nachricht in Ordnung.
6. Wiederholen Sie den Vorgang, bis der Arbeitsbereich für die beabsichtigten Änderungen sauber ist.

4. Nach GitHub (oder Remote) pushen

Nach allen Batches:

• Wenn origin (oder das benannte Remote des Benutzers) existiert und der Branch veröffentlicht werden soll, führen Sie git push -u origin HEAD aus, wenn ein Upstream fehlt, andernfalls git push.
• Führen Sie niemals git push --force auf main oder master aus.
• Wenn der Push abgelehnt wird, melden Sie den Fehler und schlagen Sie Pull/Rebase vor; führen Sie kein git push --force aus, es sei denn, der Benutzer fordert dies ausdrücklich.
• Wenn es kein Remote gibt, sagen Sie, dass die Commits nur lokal sind, und fragen Sie, ob ein Remote hinzugefügt werden soll.

5. Bericht

Fassen Sie zusammen:

• Jeder Commit-Hash und -Titel (neuester zuletzt oder nummerierte Liste).
• Push-Ergebnis (URL oder Branch, falls verfügbar).
• Alles, was absichtlich ungestellt geblieben ist (Geheimnisse, nur lokale Dateien).

Beziehung zu commit-msg

commit-msg schlägt eine Zeile aus bereits gestellten Dateien vor und führt keinen Commit durch. Diese Skill plant, staged, comitted in mehreren Schritten und pusht.