
Pull Request
Ein Pull Request, kurz PR, ist der Vorschlag einer Änderung an einem gemeinsam entwickelten Programm. Andere Beteiligte sehen die Änderung, kommentieren sie und übernehmen sie erst nach Prüfung in die offizielle Version.
Software entsteht selten allein. Oft arbeiten viele Menschen gleichzeitig an denselben Dateien eines Programms. Damit sich niemand gegenseitig die Arbeit überschreibt, wird der offizielle Stand des Programms an einer zentralen Stelle verwahrt. Wer etwas ändern will, arbeitet zuerst an einer eigenen Kopie. Ist er fertig, reicht er die Änderung als Vorschlag ein: Das ist ein Pull Request, kurz PR. Der Name bedeutet wörtlich „Bitte um Übernahme“ — die Verantwortlichen entscheiden, ob der Vorschlag in die offizielle Version wandert.
PRs als Qualitätsschleuse im Code
Ein PR ist die Stelle, an der Fehler auffallen, bevor sie Schaden anrichten. Mindestens ein zweiter Mensch liest die Änderung und stellt Fragen. Dieses Vier-Augen-Prinzip heißt in der Branche Code Review. Studien und Erfahrung zeigen: Viele Fehler werden dabei früh entdeckt und sind dann noch billig zu beheben.
Fast genauso wichtig ist die Dokumentation. Jeder PR enthält eine Beschreibung, eine Diskussion und den genauen Vergleich von altem und neuem Zustand. Wer Jahre später wissen will, warum eine Zeile so aussieht, findet dort die Begründung. Bei großen Projekten sind das hunderttausende nachlesbare Entscheidungen.
Für Unternehmen hat das auch eine rechtliche Seite. In regulierten Bereichen wie Banken oder Medizintechnik muss belegbar sein, wer eine Änderung geprüft und freigegeben hat. Der PR liefert diesen Nachweis automatisch mit. Deshalb ist er längst nicht mehr nur ein Werkzeug für Programmierer, sondern Teil der Unternehmensabläufe.
Vom Branch bis zum Merge
Am Anfang steht ein sogenannter Branch, ein abgetrennter Nebenstrang des Projekts. Dort darf man frei experimentieren, ohne den funktionierenden Hauptstand zu gefährden. Man kann sich das wie eine Fotokopie eines Textes vorstellen, in die man hineinschreibt. Erst wenn die Fassung überzeugt, soll sie das Original ersetzen.
Der PR öffnet die Diskussion darüber. Auf Plattformen wie GitHub oder GitLab sieht man Zeile für Zeile, was gelöscht und was hinzugefügt wurde. Andere hinterlassen Kommentare direkt an der betreffenden Zeile. Der Autor arbeitet die Anmerkungen ein und lädt eine verbesserte Fassung nach.
Parallel laufen automatische Prüfungen. Testprogramme kontrollieren, ob die Software weiterhin das Erwartete tut, und melden Formfehler. Sind alle Prüfungen grün und liegt eine Freigabe vor, folgt der Merge: Die Änderung wird in den Hauptstand eingefügt. Bei Konflikten, wenn also zwei Leute dieselbe Zeile geändert haben, muss der Autor von Hand entscheiden, welche Version gilt.
PRs in Open Source und bei KI-Assistenten
Am sichtbarsten sind Pull Requests in Open-Source-Projekten, deren Programmcode öffentlich einsehbar ist. Wer einen Fehler in einer freien App findet, kann selbst eine Korrektur einreichen. Große Projekte erhalten so täglich Beiträge von Fremden. Ein akzeptierter PR in einem bekannten Projekt gilt in Bewerbungen als handfester Nachweis von Können.
In Tech-News taucht der Begriff oft im Zusammenhang mit KI-Programmierhilfen auf. Werkzeuge wie GitHub Copilot oder Claude Code erledigen Aufgaben inzwischen selbstständig und reichen das Ergebnis als PR ein. Der Mensch wird damit vom Schreiber zum Prüfer. Genau darüber wird gestritten: Wenn eine Maschine hunderte PRs produziert, wer liest sie noch sorgfältig?
Eine Verwechslung lohnt die Erwähnung. Im Wirtschaftsteil steht „PR“ meist für Public Relations, also Öffentlichkeitsarbeit. In Software-Kontexten ist fast immer der Pull Request gemeint. Bei GitLab heißt dasselbe Verfahren übrigens Merge Request — der Ablauf ist identisch, nur der Name unterscheidet sich.