Pull-Request-Beschreibungen auf GitHub diktieren

Der Diff sagt bereits, was sich geändert hat. Die Beschreibung soll sagen, warum, und das ist Fließtext. Genau den sparen sich viele, weil das Tippen das Letzte ist, was zwischen ihnen und einem gemergten Branch steht.

Das PR-Besondere: Der Text ist vorausgefüllt

Wenn das Repository eine Datei .github/pull_request_template.md hat, lädt GitHub sie beim Öffnen des PR in das Beschreibungsfeld. Du diktierst also kein ganzes Dokument, sondern in die Lücken zwischen bereits vorhandenen Überschriften. Das ist einfacher, nicht schwerer, solange du den Cursor bewusst setzt:

1. Lies zuerst die Vorlage und entscheide, was unter welche Überschrift kommt, bevor du anfängst zu sprechen.
2. Klicke in die leere Zeile unter einer Überschrift, diktiere diesen Abschnitt, höre auf und klicke dann in den nächsten.
3. Diktiere nicht in einem Rutsch durch. Ein gesprochenes "new line" unter der falschen Überschrift vergräbt den Testplan in der Zusammenfassung.

Die Falle: Diktierte Klammern haken die Checkliste ab

Die meisten PR-Vorlagen sind Checklisten, geschrieben als Aufgabenlisten. Ein diktiertes "open bracket x close bracket" erzeugt ein angehaktes Kästchen. Das tut auch ein überzähliges, automatisch ergänztes Klammerpaar. Wer eine Vorlage liest, in der jedes Kästchen angehakt ist, geht davon aus, dass du die Prüfungen durchgeführt hast. Sieh dir im Tab "Preview" an, ob Kästchen ungewollt angehakt sind, bevor du den PR öffnest.

Die Auswahl für Erwähnungen und Issues verhält sich hier genauso wie in Issues: Ein diktiertes "at" öffnet die Nutzer-Autovervollständigung, ein diktiertes "hash" die Issue-Auswahl. Mit Command+Return sendest du ab.

Was du diktierst und was du tippst

• Diktieren: die Motivation, den Ansatz, den Kompromiss, den du eingegangen bist, und den, den du verworfen hast, sowie das Risiko, das sich ein Reviewer am genauesten ansehen soll. Das alles ist Fließtext, und genau das macht ein Review schnell.
• Diktieren: den Testplan als gesprochene Sätze, danach formatierst du ihn als Aufzählung.
• Tippen: Dateipfade, Funktionsnamen, Flag-Namen, Versionsnummern und alles in einem Codeblock. Die Spracherkennung trifft Groß- und Kleinschreibung und Trennzeichen oft nicht, und ein falscher Bezeichner schickt einen Reviewer zur falschen Datei.

Die Beschreibung diktieren

1. Schalte die Diktierfunktion einmalig ein: Systemeinstellungen → Tastatur → Diktierfunktion. Alle Schritte findest du unter Diktierfunktion in macOS aktivieren.
2. Öffne den Pull Request und klicke Abschnitt für Abschnitt in das Beschreibungsfeld.
3. Diktiere den Text für diesen Abschnitt und höre auf, bevor du den Cursor bewegst.
4. Tippe die Bezeichner und Codeblöcke.
5. Öffne den Tab "Preview", prüfe Checkboxen und Erwähnungen und sende dann ab.

Wenn gar nichts getippt wird

• GitHub läuft im Browser, deshalb gehört die Mikrofonberechtigung dem Browser und dem Diktierwerkzeug, unter Systemeinstellungen → Datenschutz & Sicherheit → Mikrofon.
• Diktieren funktioniert überall nicht, nicht nur in GitHub: Diktierfunktion funktioniert am Mac nicht.

Ein Kürzel vom Editor bis zum Review

Voice Type fügt den fertigen Text in einem Zug ein, statt Tastenanschläge zu streamen. Die Autovervollständigungen bleiben also geschlossen, und dasselbe Kürzel funktioniert im Editor, im Terminal und im Review-Thread: Spracheingabe für den Mac.

Weiterlesen

• GitHub-Issues diktieren, ohne Fremde zu benachrichtigen
• Spracheingabe in VS Code (und die Vervollständigungs-Engine, die deine Kommentare bearbeitet)
• Diktieren in Cursor

Quellen

• GitHub Docs: Creating a pull request template for your repository
• GitHub Docs: About task lists
• GitHub Docs: Keyboard shortcuts
• Apple: Dictate messages and documents on Mac