Commit-Messages und PR-Beschreibungen aus dem Diff entwerfen
Gute Commit-Messages und Pull-Request-Beschreibungen erklären eine Änderung heute den Reviewern und in zwei Jahren jedem, der debuggt. Aber am Ende einer langen Aufgabe ist das Schreiben des Warum statt nur des Was die Ecke, die fast jeder abschneidet. Aktuelle Codeänderungen zusammenzufassen gehört zu den fünf häufigsten KI-Aufgaben; den Diff einem Modell zu geben liefert einen strukturierten Entwurf, den Sie dann um die Begründung ergänzen, die es nicht sehen kann.
Sie helfen mir, aus einem Diff eine klare Commit-Message und Pull-Request-Beschreibung zu schreiben. Folgen Sie den Konventionen meines Teams. Commit-Konvention (zum Beispiel Conventional Commits) oder „keine“: {{convention}} Warum ich diese Änderung gemacht habe — die Absicht, die ein Diff nicht zeigen kann: {{intent}} Der Diff: {{diff}} Erstellen Sie zwei Dinge: 1. Eine Commit-Message: eine prägnante Betreffzeile (Imperativ, etwa 50 Zeichen, gemäß {{convention}} falls angegeben), eine Leerzeile, dann ein Fließtext, der erklärt, was sich geändert hat und warum, umgebrochen bei 72 Zeichen. Verweisen Sie auf das Issue als „[ISSUE]“, das ich noch ausfülle. 2. Eine PR-Beschreibung: eine einabsätzige Zusammenfassung, eine Liste der wesentlichen Änderungen, einen Abschnitt „Testanleitung“ und einen Hinweis „Risiko / Rollback“. Regeln: - Beschreiben Sie nur, was tatsächlich im Diff steht. Behaupten Sie nicht, dass Tests hinzugefügt, Dokumentation aktualisiert oder ein Bug behoben wurde, sofern der Diff das nicht zeigt. Markieren Sie alles, was Sie aus dem Diff nicht bestätigen können, als „[VERIFY]“. - Das Warum muss aus meinen Absichtsnotizen stammen, nicht aus Ihrer Vermutung über meine Motivation. - Kein Füllmaterial, keine zeilenweise Wiedergabe des Codes, kein Marketing-Ton.
Tragen Sie Ihre Angaben ein — der Prompt aktualisiert sich live. Dann kopieren.
feat(api): Nutzer-Berechtigungsabfragen cachen Berechtigungsprüfungen trafen bei jeder Anfrage die DB und erhöhten die Latenz. Aufgelöste Berechtigungen pro Nutzer 60s lang cachen, um redundante Abfragen zu reduzieren. Closes [ISSUE]. --- PR-Zusammenfassung: Fügt einen kurzlebigen In-Memory-Cache für Berechtigungsabfragen hinzu. Wesentliche Änderungen: - Neuer PermissionCache mit 60s TTL - Cache wird bei Rollenänderung invalidiert Testanleitung: /me zweimal aufrufen; der zweite Aufruf sollte die DB überspringen (siehe Debug-Log). Risiko / Rollback: Cache liegt hinter dem Flag PERM_CACHE; zum Zurückrollen deaktivieren. [VERIFY] Invalidierung bei Multi-Instance-Deployments.
Der komplette Arbeitsablauf
- Stagen Sie den finalen Diff und notieren Sie eine Zeile, warum die Änderung existiert
- Generieren Sie Message und Beschreibung und korrigieren Sie dann alles, was der Diff nicht tatsächlich hergibt
- Füllen Sie Issue-Nummern und alle „[VERIFY]“-Markierungen von Hand aus
- Behalten Sie die Begründung im Fließtext — das ist der Teil, den Reviewer und Ihr künftiges Ich wirklich brauchen
Worauf Sie achten sollten
Ein Modell, das einen Diff zusammenfasst, behauptet gerne, Sie hätten Tests hinzugefügt oder ein Sicherheitsproblem behoben, obwohl das nicht stimmt — eine Commit-Historie ist ein dauerhafter Nachweis, auf den andere sich verlassen, also prüfen Sie jede Behauptung gegen den Diff, bevor Sie committen.
Diffs können Geheimnisse, Schlüssel oder interne Bezeichner enthalten. Fügen Sie sie nicht in ein Consumer-Tool ein; nutzen Sie eine freigegebene Integration oder bereinigen Sie sie zuerst.
Das Modell sieht das Was, aber nicht das Warum. Liefern Sie die Absicht selbst, sonst versenden Sie Messages, die die Änderung beschreiben, ohne die dahinterstehende Entscheidung zu erklären.
Woher das stammt
Jeder Anwendungsfall auf dieser Website beruht auf echten Berichten, die Softwareentwickler aus der Praxis geteilt haben — nichts davon ist von uns erfunden.