Devolutions/IronRDP

Commit- und PR-Konventionen

Behandle den PR-Titel und den initialen Body als die exakte Commit-Nachricht, die Squash-and-Merge landen wird.

Commit-Nachricht

• Lies zuerst die Repository-Anweisungen. Leite Scopes mit dem repository-lokalen commit-scope-Skill ab. Falls nicht verfügbar, verwende explizite Repository-Regeln oder lasse den Scope weg, anstatt einen zu erfinden.
• Folge den Conventional Commits: <Typ>[optionaler Scope][!]: <Beschreibung>.
• Ziel sind 50 Zeichen und beschreibe das resultierende Verhalten. Lasse keine repository-erforderlichen Scopes weg, um dieses Ziel zu erreichen; wenn sie dies unmöglich machen, halte die verbleibende Beschreibung so prägnant wie praktikabel.
• Trenne Betreff, Body und Fußzeilen mit Leerzeilen.
• Für eigenständige Commits, umbreche Body-Zeilen bei 72 Zeichen. Erkläre, warum die Änderung benötigt wurde, wie sie das Problem löst und welche materiellen Nebenwirkungen auftreten.
• Setze einen vorhandenen Ticket-Schlüssel oder -Link in eine Fußzeile, nicht in den Betreff: Issue: PROJECT-123. Folge dem repository-spezifischen Fußzeilenformat, wenn ein Issue existiert. Wenn keines existiert, lasse die Fußzeile weg, anstatt Issue: N/A zu erfinden.
• Füge anwendbare Conventional Commit-Fußzeilen und Co-authored-by: Name <email>-Trailer für Mitarbeiter hinzu.
• Wähle den Typ nach der betroffenen Oberfläche, nicht danach, ob die Änderung einen Fehler behebt.
• Verwende ci für CI-, Workflow- und Automatisierungsänderungen, einschließlich Fehlerbehebungen in dieser Automatisierung.
• Verwende fix für Produkt- oder Laufzeitfehler und Nicht-Feature-Änderungen an extern genutzten öffentlichen API-Grenzen.
• Verwende feat für Features, build für Build oder Abhängigkeiten, chore für Nicht-Produkt-Tools oder -Konfiguration, docs für reine Dokumentation, style für nicht-semantische Änderungen, refactor für interne Umstrukturierungen, test für Tests und perf für Performance.
• Markiere breaking changes mit ! oder einer BREAKING CHANGE-Fußzeile, ohne einen ansonsten korrekten Typ zu ändern.
• Halte jeden nicht gesquashten Entwicklungs-Commits kohärent und konventionell.

fix(storage): keep collated indexes

Normalize server-expanded collations before comparing index definitions.

Issue: PROJECT-123

Pull-Request

• Setze den Titel genau auf den beabsichtigten Squash-Commit-Betreff.
• Setze den initialen Body genau auf den beabsichtigten Squash-Commit-Body und die Fußzeilen. Schließe PR-spezifische Einleitungen, Checklisten und Implementierungsjournale aus.
• Umbrüche manuell im PR-Body sind nicht nötig; GitHub übernimmt die Darstellung automatisch.
• Halte die permanente Historie prägnant: dokumentiere Motivation, materielles Verhalten und Nebeneffekte.
• Platziere Experimente, Alternativen, umfangreiche Validierungen und Implementierungschronologie in Folgekommentaren.
• Verfasse einen Folgekommentar mit den geänderten Zeilen, aufgeteilt mindestens in Produktionscode, Tests und andere Dateien, damit ein Reviewer sieht, wo das Gewicht der Änderung liegt, bevor er sie liest; wie du diese zählst und präsentierst, liegt bei dir, und aktualisiere sie, wenn sich der Diff wesentlich ändert.
• Aktualisiere Titel und initialen Body, während die Implementierung fortschreitet.
• Vor dem Öffnen, Aktualisieren oder Mergen, lies Titel + Leerzeile + Body als eine Commit-Nachricht und korrigiere eventuelle Abweichungen.