Einen unaufgeräumten C#-Feature-Branch mit dem GitLens Commit Composer aufräumen

Wenn ich an einem echten C#-Feature-Branch arbeite, beginnt die Git-Historie fast nie so sauber, wie ich sie am Ende haben möchte.

Das liegt nicht daran, dass mir saubere Commits egal wären. Es liegt daran, dass Entwicklung explorativ ist. Ich fange vielleicht in einer Blazor-Komponente an, stelle fest, dass der API-Vertrag noch nicht ganz stimmt, wechsle in einen Application Service, passe ein DTO an, füge Validierung hinzu, mache einen Test kaputt, repariere einen Test, benenne eine Methode um und merke dann schließlich, dass die erste Commit-Nachricht die eigentliche Änderung gar nicht mehr beschreibt.

Der Code mag gut sein. Der Branch mag sogar fertig sein. Aber die Historie erzählt oft die falsche Geschichte.

Und das ist wichtig.

Ein Pull Request ist nicht nur ein Diff. Er ist ein Kommunikationsartefakt. Er sagt einem anderen Entwickler, wie er die Änderung reviewen soll, worauf er sich konzentrieren muss und wie sich die Implementierung entwickelt hat. Wenn die Historie voller "wip", "fix", "cleanup" und "actually fix tests" ist, muss der Reviewer die Absicht mühsam von Hand rekonstruieren.

Genau hier wird der GitLens Commit Composer nützlich.

Das eigentliche Problem ist nicht die Commit-Nachricht

Viele KI-gestützte Git-Werkzeuge konzentrieren sich auf Commit-Nachrichten. Das ist hilfreich, aber es reicht nicht.

Das schwierigere Problem ist die Commit-Struktur.

In einem typischen .NET-Feature-Branch kann die Arbeit Folgendes umfassen:

• einen neuen Endpoint oder eine Minimal-API-Route,
• eine Änderung in der Service-Schicht,
• eine Anpassung an einem Repository oder am Datenzugriff,
• Validierungslogik,
• Test-Fixtures,
• Unit- oder Integrationstests,
• Konfigurationsänderungen,
• und vielleicht eine kleine UI-Änderung in Blazor oder einer anderen Frontend-Schicht.

Während der Implementierung passieren diese Änderungen aus Review-Sicht oft in der falschen Reihenfolge. Das ist normal. Aber vor einem Pull Request möchte ich in der Regel, dass die Commits eine sauberere Geschichte erzählen.

Zum Beispiel:

1. Domänenmodell- und Validierungsänderungen hinzufügen.
2. Verhalten des Application Service hinzufügen.
3. API-Endpoint hinzufügen.
4. UI-Integration hinzufügen.
5. Tests hinzufügen und Randfälle beheben.

Diese Struktur hilft Reviewern. Und sie hilft auch dem zukünftigen Ich, wenn ich verstehen muss, warum ein Stück Code eingeführt wurde.

Das Entscheidende ist, dass der Commit Composer nicht nur "schreib eine bessere Nachricht für diesen gestagten Diff" bedeutet. Es geht darum, Arbeit in klarere Commits neu zusammenzusetzen.

Ein praktisches .NET-Szenario

Stell dir vor, ich füge einer SaaS-Anwendung einen Kunden-Einladungs-Flow hinzu.

Während der Implementierung könnte ich am Ende einen Branch haben, der so aussieht:

a1b2c3d wip invite
b2c3d4e fix compile
c3d4e5f add email stuff
d4e5f6a update tests
e5f6a7b rename dto
f6a7b8c fix validation

Das ist keine brauchbare Review-Geschichte.

Die tatsächliche logische Geschichte ist vermutlich eher diese:

feat(customers): add invitation request model and validation
feat(customers): implement invitation workflow service
feat(api): expose customer invitation endpoint
feat(ui): add invitation action to customer administration
test(customers): cover invitation workflow and validation failures

Diese zweite Version sagt dem Reviewer, was passiert ist. Und sie erlaubt es ihm, in Schichten zu reviewen.

Genau hier würde ich den GitLens Commit Composer einsetzen, bevor ich den PR öffne.

Wie ich den Commit Composer in der Praxis einsetzen würde

Mein Workflow würde ungefähr so aussehen:

1. Den Feature-Branch auf die normale, unaufgeräumte Weise fertigstellen.
2. Die Tests lokal ausführen.
3. Den GitLens Commit Graph öffnen.
4. Die Branch-Commits und den Working Tree durchsehen.
5. Den Commit Composer nutzen, um die Arbeit in logische Commits neu zusammenzusetzen.
6. Die vorgeschlagene Gruppierung manuell prüfen.
7. Alles anpassen, was zu grob, zu clever oder zu vage wirkt.
8. Erst dann den Pull Request öffnen.

Der entscheidende Schritt ist Nummer sechs.

Ich würde eine KI-generierte Commit-Struktur nicht blind akzeptieren. Das würde den Sinn zunichtemachen. Der Wert besteht nicht darin, dass das Werkzeug eigenes Urteilsvermögen überflüssig macht. Der Wert besteht darin, dass mir das Werkzeug einen deutlich besseren Ausgangspunkt gibt und den Aufräumprozess innerhalb der Entwicklungsumgebung hält.

Für mich ist der ideale Einsatz des Commit Composers keine Automatisierung ohne Verantwortung. Es ist unterstützte redaktionelle Arbeit an meinem Branch.

Warum das für Code Review wichtig ist

Eine gute Commit-Historie reduziert Reibung beim Review.

Ein Reviewer sollte nicht jede geänderte Datei auf einmal lesen müssen. Er sollte sich in sinnvollen Schritten durch das Feature bewegen können. Das ist besonders wichtig in C#-Codebasen, in denen architektonische Grenzen eine Rolle spielen.

Wenn ein Commit DTO-Änderungen, Datenbankänderungen, UI-Updates und Tests vermischt, muss der Reviewer zu viel Zustand im Kopf behalten.

Wenn die Commits nach Absicht getrennt sind, wird das Review einfacher:

• "Dieser Commit ändert den Vertrag."
• "Dieser Commit implementiert den Workflow."
• "Dieser Commit stellt ihn über die API bereit."
• "Dieser Commit bindet die UI an."
• "Dieser Commit beweist das Verhalten."

Diese Struktur hilft auch, wenn später etwas kaputtgeht. Eine saubere Historie zu bisecten ist einfacher, als einen Haufen "fix"-Commits zu bisecten.

Wo GitLens in meinen bestehenden Workflow passt

Ich betrachte GitLens ohnehin als eine der besten Möglichkeiten, Git-Kontext in den Editor zu bringen.

Für .NET-Arbeit ist Visual Studio Code nicht immer die einzige IDE im Bild. Viele C#-Entwickler nutzen für tieferes Debugging oder Arbeit auf Solution-Ebene weiterhin Visual Studio. Aber VS Code ist oft Teil des Workflows für Skripte, Infrastruktur, Dokumentation, Git-Operationen, Markdown, CI/CD-YAML, Dev Containers und leichtgewichtiges Editieren.

Das macht GitLens wertvoll, selbst wenn es nicht die einzige Entwicklungsfläche ist.

Der Commit Composer stärkt diese Rolle. Er gibt mir einen Grund, das finale Branch-Aufräumen an dem Ort zu erledigen, an dem ich Code-Kontext, Commit-Kontext und Branch-Historie noch zusammen sehen kann.

Das Sicherheitsdetail, das mir gefällt

Ein Detail, das ich Teams ausdrücklich erwähnen würde, ist das Signieren von Commits.

In vielen professionellen Umgebungen sind signierte Commits nicht optional. Sie sind Teil des Vertrauensmodells. Wenn ein Werkzeug Git einfacher macht, aber die Signatur-Erwartungen umgeht, schafft es ein Problem.

Ab GitLens 17.10 respektieren die Commit-Operationen in GitLens, einschließlich des Commit Composers, die bestehende Konfiguration für das Signieren von Git-Commits. Das ist ein kleiner Satz in den Release Notes, aber ein großes praktisches Detail für Teams, die Repository-Richtlinien ernst nehmen.

Das KI-Detail, das mich wirklich interessiert

Die Verbesserung in GitLens 17.11 vom März 2026, die für mich heraussticht, ist die kontextbewusste Komposition.

Der Commit Composer kann bestehende Commits auf dem Branch als Kontext nutzen, wenn er neue Änderungen komponiert. Das ist wichtig, weil ein Branch eine Erzählung hat. Wenn die ersten beiden Commits bereits einem bestimmten Scope und Stil folgen, sollte sich der nächste generierte Commit nicht anfühlen, als käme er aus einem anderen Projekt.

Genau hier ist KI nützlich: nicht als Ersatz für das Review, sondern als Weg, Konsistenz über sich wiederholende, kontextreiche Entwickleraufgaben hinweg zu bewahren.

Wo ich es nicht einsetzen würde

Ich würde den Commit Composer nicht als Ersatz dafür einsetzen, meine eigenen Änderungen zu verstehen.

Wenn ein Branch riskant, sicherheitskritisch ist oder Datenmigrationslogik berührt, möchte ich noch vorsichtiger sein. In solchen Fällen würde ich das Werkzeug trotzdem nutzen, aber nur als Entwurf. Ich würde jeden generierten Commit, jede gestagte Datei und jede Nachricht prüfen.

Das Werkzeug kann helfen, die Arbeit zu strukturieren. Es kann die Verantwortung nicht übernehmen.

Diese Unterscheidung ist wichtig für die Glaubwürdigkeit. KI-gestützte Git-Workflows sind nützlich, aber nur, solange der Entwickler in der Verantwortung bleibt.

Fazit

Der GitLens Commit Composer ist nützlich, weil er ein echtes Problem adressiert: die Lücke zwischen der Art, wie wir Software bauen, und der Art, wie wir Software fürs Review präsentieren sollten.

In echter .NET-Arbeit sind Feature-Branches unaufgeräumt, weil Problemlösen unaufgeräumt ist. Aber Pull Requests sollten Reviewer nicht zwingen, diese Unordnung aufzunehmen. Eine saubere Git-Historie ist ein Zeichen von Respekt gegenüber dem Team.

Deshalb mag ich dieses Feature. Nicht, weil es KI zu Git hinzufügt, sondern weil es hilft, einen Branch in eine bessere technische Erzählung zu verwandeln, bevor das Review beginnt.