GitHub öffnet eine neue Pull-Request-Übersicht als freiwillige öffentliche Vorschau: kompakte Merge-Zusammenfassung und Kommentarfilter, doch der Changelog nennt keine Tarife oder Produkte, kein Enddatum und sagt nichts zur Darstellung von Merge-Queue oder Regelsätzen

Am 5. November 2026 kündigte GitHub eine neue Übersichtsseite (Overview) für Pull Requests als freiwillige öffentliche Vorschau an. Laut Changelog läuft die Auslieferung über das Wochenende weiter, nicht jedes Konto sieht sie also sofort. Der erste Schritt ist schmal: Die Seite stellt Merge-Status und die nächsten möglichen Aktionen oben in einer kompakten Bereitschaftsübersicht an den Anfang eines Pull Requests und bietet einige Wege, eine lange Diskussion nachzuvollziehen. Die Quelle ist ein kurzer Changelog-Eintrag ohne Messwerte; dieser Beitrag beschreibt deshalb, was der Eintrag sagt, ergänzt Hintergrund aus GitHubs eigener Merge-Dokumentation und nennt, was der Eintrag offenlässt.

Der Anlass ist ein bekanntes Ärgernis. Bei einem langen Pull Request kann es nötig sein, an Dutzenden Kommentaren und Zeitleistenereignissen vorbeizuscrollen, um herauszufinden, was den Merge blockiert, und danach muss man selbst klären, was als Nächstes zu tun ist. GitHub sagt, man habe begonnen, die gesamte Pull-Request-Erfahrung neu zu denken, und fange damit an. Die Merge-Box wurde neu gestaltet und zeigt dieselben Informationen auf weniger als der Hälfte des Platzes. Sie hat drei Aufgaben: die stützenden Signale, also Prüfungen, Kommentare und Genehmigungen, kompakt zeigen; es ermöglichen, auf Blockaden zu reagieren, als Beispiel wird das Aktualisieren des Branches genannt; und anzeigen, ob der Pull Request mergebereit ist, mit der Möglichkeit zu mergen, sobald die Anforderungen erfüllt sind. Der Eintrag empfiehlt, zuerst die Übersicht zu lesen und dann dem Detail zu folgen, das man braucht, etwa fehlgeschlagene Prüfungen, offene Genehmigungen oder die betreffenden Kommentare.

Drei weitere Änderungen helfen, einer Diskussion zu folgen. Man kann die Unterhaltung auf ungelöste Konversationen oder eigene Kommentare filtern, was offene Fragen und die Nachverfolgung des eigenen Feedbacks erleichtert. Man kann Kommentare vom neuesten zum ältesten sortieren, statt mit der frühesten Diskussion zu beginnen. Und eine Zusammenfassung oben rechts listet Review-Kommentare, Review-Anfragen und andere Aktualisierungen. Über die Kopfzeile lässt sich außerdem ein Entwurf als bereit für das Review markieren oder der Pull Request schließen; welche Aktionen erscheinen, hängt von den Berechtigungen ab.

Zum Ausprobieren wählt man in der Kopfzeile die Schaltfläche „Try the Overview page“. Über dasselbe Menü kommt man während der Vorschau zur klassischen Übersicht zurück, die Änderung ist also pro Nutzer umkehrbar. GitHub nennt die Vorschau einen Anfang und nicht die fertige Erfahrung und bittet in einer Community-Diskussion um Rückmeldungen. Zum Zeitpunkt der Erfassung zeigte dieser Diskussionsbeitrag keine Kommentare.

Als Hintergrund beschreibt GitHubs Dokumentation zum Mergen eines Pull Requests die Regeln, die die Übersicht abbilden muss. Ein Entwurf eines Pull Requests kann nicht gemergt werden. Repository-Regeln oder Branch-Schutz können Reviews, Statusprüfungen oder einen aktuellen Branch verlangen, und Regelsätze werden als Alternative zu Branch-Schutzregeln angeboten. Ein Pull Request kann so eingestellt werden, dass er automatisch mergt, sobald alle Anforderungen erfüllt sind. Verlangt der Basis-Branch eine Merge-Queue, unterscheiden sich die verfügbaren Merge-Optionen von den üblichen. Es gibt drei Merge-Methoden, den Merge-Commit, den Squash-Merge und den Rebase-Merge, und die Dokumentation weist darauf hin, dass „Rebase and merge“ immer die Committer-Angaben aktualisiert und neue Commit-SHAs erzeugt. Wir führen das nur als Hintergrund an: Der Changelog sagt nicht, wie die Übersichtsseite den Zustand der Merge-Queue, Regelsätze oder Auto-Merge anzeigt, und wir schließen es nicht daraus.

Mehrere praktische Fragen bleiben im Eintrag unbeantwortet. Er sagt nicht, welche GitHub-Tarife oder -Produkte eingeschlossen sind, auch nicht GitHub Enterprise Server; Teams, die diese nutzen, sollten das prüfen, bevor sie damit rechnen. Er nennt kein Ende der Vorschau und keinen Plan, die neue Seite zum Standard zu machen. Er sagt nicht, ob die Seite etwas für die API, die GitHub-CLI oder das Benachrichtigungsverhalten ändert, und er liefert keine Messung, dass das neue Layout Zeit spart. Die Aussage „weniger als die Hälfte des Platzes“ ist eine Entwurfsaussage zur Merge-Box, kein Ergebnis zur Bedienbarkeit.

Unsere Einschätzung: Es ist eine bescheidene Oberflächenänderung, die sich billig ausprobieren lässt, weil sie freiwillig und umkehrbar ist. Profitieren dürften Reviewer langer Pull Requests, vor allem durch die Filter und die Sortierung nach neuesten Kommentaren zuerst. Ein Team, das von einer bestimmten Merge-Einrichtung abhängt, etwa einer Merge-Queue oder Auto-Merge, sollte die Vorschau an einem Test-Pull-Request ausprobieren und beide Übersichten vergleichen, bevor es alle zum Umstieg auffordert.