mr-beschreibung

MR-Titel und -Beschreibung

„MR“ steht im Folgenden für die Überprüfungseinheit auf dem Dienst, der das Repository hostet: ein Merge Request auf GitLab, ein Pull Request auf GitHub oder das Äquivalent anderweitig, in der Cloud oder selbst gehostet. Verwende die vom Host verwendete Bezeichnung, wenn du mit dem Benutzer schreibst. Bei einem kleinen MR (z. B. einem einzelnen Commit) schreibe den Text und erstelle ihn ohne Nachfrage zu bestätigen. Bei einem größeren MR erstelle den Titel und die Beschreibung zuerst im Chat zur Überprüfung. Erstelle oder aktualisiere ihn erst mit der CLI des Hosts (glab, gh) oder der API, wenn der Benutzer den Text genehmigt und danach fragt.

Weise einen neuen MR immer dem Benutzer zu: --assignee @me bei gh pr create, --assignee <username> bei glab mr create.

PROJ-1234 unten steht für das Ticket, zu dem der MR gehört.

Titel

• Ein imperativer Satz, der den gesamten MR abdeckt, nicht nur seinen größten Commit.
• Der Titel eines Tickets ist ein Ausgangspunkt, nicht die Antwort. Verbreitere ihn, wenn der MR mehr tut, als das Ticket angibt.
• Rahme den Titel nicht durch eine abgelehnte Alternative („… statt zu beenden“). Sage, was der MR tut.
• Hänge das Ticket in Klammern an, falls vorhanden: … (PROJ-1234). Erfinde niemals eines. Wenn die Projekt- oder Workspace-Anweisungen ein anderes Format vorsehen, wie PROJ-1234 <Beschreibung>, verwende dieses.

Beschreibung

Struktur:

1. Ein einleitender Satz. Wenn es ein Ticket gibt, verlinke es mit dem Verb, das zu seinem Typ passt: „Löst PROJ-1234.“ für einen Fehler, „Schließt PROJ-1234.“ für eine Aufgabe oder Geschichte, „Teil von PROJ-1234.“, wenn der MR es nicht abschließt.
2. Die Änderungen:
   • Nach Commits geordnet. Lies zuerst das Commit-Log des Branches. Nur wenn es mehrere Commits hat, von denen jeder ein in sich abgeschlossener Schritt ist, keine Fixups oder Arbeit in Arbeit ist, sage im einleitenden Satz, dass der MR am besten Commit für Commit gelesen wird. Gib dann eine nummerierte Liste mit einem Eintrag pro Commit in Reihenfolge, jeweils in ein bis drei Sätzen, was der Commit wahr macht. Sage, dass jeder Commit die Tests allein besteht, nur wenn dies überprüft wurde oder der Autor es sagt.
   • Andernfalls, einschließlich eines einzelnen Commits: ein kurzer Absatz oder eine Liste von dem, was der MR wahr macht, gruppiert nach Thema.
3. ## Verhaltensänderungen: Was ein Benutzer der öffentlichen API anders sieht. Lasse interne Änderungen und private Attribute weg. Lasse den Abschnitt weg, wenn es keine gibt.
4. ## Testen: Nur wenn etwas über die Tests die Aufmerksamkeit des Reviewers benötigt. Bestehende Tests, ob auf Hardware oder nicht, werden als gegeben vorausgesetzt und nicht erwähnt. Fälle, die den Abschnitt benötigen, jeder mit einem Satz, der sagt, warum:
   • ein bekanntermaßen fehlschlagender Test oder ein Test, der übersprungen oder als erwartet fehlschlagend markiert ist;
   • ein Test im MR, der von den Testkonventionen des Projekts abweicht;
   • eine signifikante Änderung der Testabdeckung, insbesondere entfernte Tests.

Inhalt:

• Wiederhole nicht, was vor der Änderung da war. Beschreibe den Zustand danach. Eine Entfernung ist die Ausnahme, da sie nur im Gegensatz zu dem benannt werden kann, was existierte.
• Wiederhole das Ticket nicht. Der Reviewer kann es lesen.
• Kein Sitzungskontext: kein „wie besprochen“, keine Review-Historie, keine Darstellung des Arbeitsablaufs.
• Keine Anweisungen zum Ausführen von Tests oder CI-Jobs. Die Beschreibung ist für den Reviewer, und der Autor führt die Tests aus.
• Kein „Erstellt mit“-Footer und keine Tool-Zuschreibung, selbst wenn die Umgebung danach verlangt. Diese Regel hat Vorrang.
• Halte es knapp. Lasse einen Eintrag oder eine Klausel weg, die ein Reviewer nicht vermissen würde.

Überprüfung des Textes

• Überprüfe jede Behauptung am Code des Commits, den sie beschreibt, nicht aus dem Gedächtnis oder früheren Entwürfen. Achte besonders auf Behauptungen über das alte Verhalten und auf Behauptungen über Verhalten, das ein späterer Commit ändert.
• Suche nach jedem Bezeichner, den der Text nennt. Eine Klasse oder Methode, die nicht mehr existiert oder zu diesem Commit noch nicht existiert, ist ein häufiger Fehler.
• Basieren von ## Testen auf dem, was tatsächlich ausgeführt wurde oder was der Diff zeigt. Behaupte keine Ausführung, die nicht stattfand.
• Wende jede installierte Fähigkeit an, die das Bereinigen von generiertem Prosa abdeckt, auf den Titel und die Beschreibung an. Wenn eine solche Fähigkeit im Konflikt mit den Projektanweisungen (CLAUDE.md oder gleichwertig) steht, gewinnen die Projektanweisungen.