Copilot darf jetzt Pull Requests freigeben

Seit dem 01.09.2026 kann GitHub Copilot Pull Requests freigeben. Nicht nur kommentieren, sondern eine Freigabe abgeben, die auf die Regel "erforderliche Freigaben" des Repositories angerechnet wird. Damit kann eine KI formal das Merge-Tor öffnen. Die Funktion ist in Public Preview und standardmäßig aus.

Das Feature ist besser gebaut, als die Schlagzeile vermuten lässt. Trotzdem ist es das erste, bei dem ihr vor dem Einschalten mit jemandem außerhalb des Entwicklungsteams reden solltet.

Was genau passiert

GitHub hat zwei Dinge ausgeliefert, die man auseinanderhalten sollte.

Die Einschätzung. Jedes Copilot-Review enthält ab sofort im Übersichtskommentar eine Einschätzung, ob Copilot den Pull Request für freigabereif hält. Die ist immer da und für niemanden verbindlich. GitHub schreibt dazu: "An approval assessment alone does not count toward merge requirements."

Die echte Freigabe. Das ist die neue Funktion, und die ist optional. Im Wortlaut: "By default, Copilot will not approve pull requests. When enabled, Copilot can submit an approval that counts toward the repository's required-approvals rule."

Die Steuerung läuft auf drei Ebenen:

Ebene	Was Admins entscheiden können
Enterprise	Freigaben für das gesamte Unternehmen aus lassen, oder die Entscheidung an die Organisationen abgeben
Organisation	Organisationsweit an, an einzelne Repositories delegiert, für bestimmte Repositories an, oder organisationsweit aus
Repository	An oder aus, und die Auswahl, welche Dateipfade Copilot überhaupt freigeben darf

Werden nach der Freigabe neue Commits gepusht, verfällt sie. GitHub formuliert das so: "If new commits are pushed after Copilot approves, its approval is dismissed just like a human reviewer's". Ein neues Review lässt sich dann anfordern.

Verfügbar ist das für Copilot Pro, Pro+, Max, Business und Enterprise.

Der Aufhänger: euer Vier-Augen-Prinzip

In vielen Teams ist die Pflicht-Freigabe im Repository kein Komfortfeature, sondern die technische Umsetzung einer Zusage. Sie steht in einer Zertifizierung, in einem Kundenvertrag, in einer internen Richtlinie zur Aufgabentrennung oder in einer Verfahrensdokumentation. Wer die Regel technisch erfüllt, gilt als konform.

Genau da wird es interessant. Die Regel "mindestens eine Freigabe" prüft eine Zahl, nicht ein Augenpaar. Wenn Copilot diese Zahl liefern darf, ist die Regel weiterhin erfüllt, während sich das, was sie eigentlich absichern sollte, verändert hat.

Das ist kein Vorwurf an GitHub. Die Funktion ist aus gutem Grund standardmäßig aus und auf drei Ebenen abschaltbar. Aber die Entscheidung, sie einzuschalten, ist keine Entwicklerentscheidung. Sie berührt eine Zusage, die jemand anderes gegeben hat.

Wir können euch nicht sagen, ob eure konkrete Zertifizierung oder euer konkreter Kundenvertrag einen maschinellen Reviewer als zweites Augenpaar akzeptiert. Das hängt am Wortlaut, und den kennt nur ihr. Was wir sagen können: Diese Frage sollte beantwortet sein, bevor der Schalter umgelegt wird, und nicht danach.

Drei Dinge, die ihr vorher klären solltet

1. Was steht in eurer eigenen Zusage?

Sucht die Stelle, an der euer Review-Prozess beschrieben ist. Steht dort "ein zweiter Entwickler", "eine zweite Person", "ein unabhängiger Reviewer" oder einfach "eine Freigabe"? Der Unterschied entscheidet, ob ihr die Funktion einschalten könnt, ohne die Formulierung anzupassen. Falls ihr auditiert werdet: Das ist eine Frage für den Auditor, und eine, die man besser vorher stellt als beim nächsten Termin.

2. Copilot liest nicht alles

Das ist der Punkt mit dem größten praktischen Sprengstoff, und er steht in GitHubs eigener Dokumentation. Bestimmte Dateitypen werden von Copilot-Reviews grundsätzlich ausgenommen:

Dependency-Management-Dateien, also zum Beispiel package.json und Gemfile.lock
Logdateien
SVG-Dateien

Im Wortlaut: "If you include these file types in a pull request, Copilot code review will not review the file."

Ausgerechnet die Abhängigkeitsdateien. Das sind die Dateien, über die Supply-Chain-Angriffe laufen, und die, bei denen ein aufmerksamer Mensch stutzig wird, wenn da plötzlich ein Paket mit ähnlich klingendem Namen auftaucht.

Ob Copilot einen Pull Request, der nur solche Dateien anfasst, trotzdem freigeben würde, steht in der Dokumentation nicht. Das ist eine offene Frage und keine Behauptung. Sie ist aber leicht zu beantworten: Baut in einem Testrepository einen Pull Request, der ausschließlich package.json ändert, und schaut nach, was passiert. Genau dafür gibt es auf Repository-Ebene die Einschränkung nach Dateipfaden. Wenn ihr die Funktion einschaltet, ist das der Ort, an dem ihr Abhängigkeitsdateien ausnehmen solltet.

3. GitHub selbst empfiehlt weiterhin den Menschen

In derselben Dokumentation, die das Feature beschreibt, steht dieser Satz: "Copilot is not guaranteed to spot all problems or issues in a pull request. Sometimes it will make mistakes. Always validate Copilot's feedback carefully. Supplement Copilot's feedback with a human review."

Das ist bemerkenswert. Der Hersteller liefert eine Funktion aus, mit der Copilots Freigabe die Pflicht-Freigabe ersetzen kann, und rät im selben Atemzug dazu, ein menschliches Review zu ergänzen. Man kann das als Widerspruch lesen. Fairer ist die Lesart, dass GitHub das Werkzeug bereitstellt und die Verantwortung bewusst bei euch lässt. Genau deshalb ist es standardmäßig aus.

Wo das wirklich hilft

Bei aller Vorsicht: Es gibt Fälle, in denen diese Funktion ein echtes Problem löst.

Ein-Personen-Repositories und kleine Teams. Wer allein an einem internen Werkzeug arbeitet, hat die Pflicht-Freigabe bisher entweder ausgeschaltet oder umgangen. Beides ist schlechter als ein Review, das wenigstens stattfindet.

Abhängigkeits-Updates und Routinearbeit. Ein Renovate-Bot öffnet dreißig Pull Requests pro Woche, und irgendwann klickt jemand nur noch durch. Ein Maschinenreview, das tatsächlich in den Diff schaut, ist besser als ein menschliches, das es nicht tut. Zu dieser Sorte Selbstbetrug haben wir die Zahlen in Die 79-Prozent-Falle zusammengetragen.

Zeitzonen. Ein Team über drei Kontinente wartet manchmal einen Tag auf eine Freigabe für einen Einzeiler.

Die Kunst liegt in der Abgrenzung. Copilot für docs/, für Tests und für Übersetzungsdateien freigeben zu lassen und für alles unter auth/, payment/ und die Abhängigkeitsdateien nicht, ist eine vernünftige Konfiguration. Der Schalter ist nicht binär, und ihr solltet ihn nicht binär benutzen.

Was das für euch heißt

Für Entwickler: Die Einschätzung im Übersichtskommentar bekommt ihr ab sofort, ohne etwas zu tun. Sie ist unverbindlich und als Vorsortierung nützlich.

Für QA: Ein grünes Copilot-Review sagt nichts über package.json, Logdateien und SVGs aus, weil Copilot sie gar nicht erst liest. Genau diese Dateien gehören weiter auf euren Prüfzettel.

Für Projektleiter: Wenn ihr einschaltet, dann pfadgenau. Abhängigkeitsdateien, Sicherheitscode und Infrastrukturdefinitionen gehören nicht dazu.

Für Product Owner: Klärt vorher, ob eure Prozessdokumentation eine maschinelle Freigabe abdeckt. Das ist billiger als eine Nachfrage im Audit.

Für alle: Die Freigabe verfällt bei neuen Commits, genau wie bei einem menschlichen Reviewer. Das ist die wichtigste eingebaute Sicherung, und sie funktioniert nur, wenn ihr sie nicht durch Force-Push aushebelt.

Die Frage hinter dem Feature ist älter als das Feature. Ein Review, das niemand ernsthaft macht, war noch nie ein Review, auch wenn ein Mensch draufgeklickt hat. Wer den Schalter jetzt bewusst konfiguriert, hat gute Chancen, am Ende einen ehrlicheren Prozess zu haben als vorher. Wer ihn organisationsweit anschaltet, weil es bequem ist, hat eine Kennzahl gerettet und eine Kontrolle verloren.