Pull-Request-Workflow auf GitHub

Ein Pull Request (PR) ist ein Vorschlag, einen Branch in einen anderen zu mergen. Auf GitHub wird dadurch ein Diskussionsverlauf erstellt, in dem Teammitglieder den Code prüfen, Kommentare hinterlassen, Änderungen anfordern und den Merge schließlich genehmigen können.

Nachdem Sie einen Feature-Branch zu GitHub gepusht haben, erscheint ein gelbes Banner, das Ihnen anbietet, die Branches zu vergleichen und einen PR zu erstellen. Klicken Sie darauf oder gehen Sie zu Pull Requests → New pull request und wählen Sie Ihre Branches aus.

Eine gute PR-Beschreibung erklärt, was geändert wurde und warum. Fügen Sie bei UI-Änderungen einen Screenshot ein. Verlinken Sie das zugehörige Issue. Beschreiben Sie, wie Sie die Änderungen getestet haben. Die lesende Person sollte die Absicht verstehen können, ohne den Code lesen zu müssen.

Weisen Sie bestimmte Teammitglieder als Reviewer zu. Sie erhalten eine Benachrichtigung und können den PR genehmigen, Änderungen anfordern oder kommentieren. Die meisten Teams verlangen vor dem Mergen mindestens eine Genehmigung.

Kommentare erscheinen inline in den geänderten Zeilen. Reviewer können um Erläuterungen bitten, einen anderen Ansatz vorschlagen oder den PR genehmigen. Antworten Sie auf jeden Kommentar — entweder mit einer Codeänderung oder mit einer Begründung, warum Sie nichts ändern.

Wenn ein Reviewer Änderungen anfordert, pushen Sie neue Commits in denselben Branch. Der PR wird automatisch aktualisiert. Schließen Sie jede Diskussion, indem Sie nach der Umsetzung auf 'Resolve conversation' klicken.

Öffnen Sie einen PR als Draft, um zu signalisieren, dass er noch in Bearbeitung ist. Draft-PRs können weiterhin geprüft und diskutiert werden, lassen sich aber nicht versehentlich mergen. Wandeln Sie den PR in Ready um, sobald er fertig ist.

Wenn main während der Prüfung weiterentwickelt wird, führen Sie einen Rebase Ihres Branches auf den aktuellen Stand von main durch, um Konflikte zu vermeiden und sicherzustellen, dass Ihre Änderungen mit dem neuen Code funktionieren.

GitHub bietet drei Merge-Strategien: Merge commit (erhält alle Commits), Squash and merge (ein Commit pro PR, übersichtliche main-Historie), Rebase and merge (linear, ohne Merge-Commit). Teams wählen aus Gründen der Einheitlichkeit normalerweise eine Strategie.

Schützen Sie main, indem Sie eine PR-Prüfung voraussetzen, erfolgreiche Statusprüfungen (CI) verlangen und direkte Pushes verbieten. Legen Sie dies unter GitHub → Settings → Branches fest.

Halten Sie PRs klein und fokussiert. Ein PR pro Feature oder Fehlerbehebung. Große PRs sind schwer zu prüfen. Antworten Sie innerhalb eines Tages auf Review-Kommentare. Bedanken Sie sich bei den Reviewern. Seien Sie freundlich — ein Code-Review ist eine Gelegenheit zum Lernen, keine Prüfung.

Was sollte eine gute PR-Beschreibung enthalten?

Feature-Branch pushen → einen PR mit einer klaren Beschreibung öffnen → Reviewer anfordern → Feedback mit neuen Commits umsetzen → den Branch durch Rebase aktuell halten → Genehmigung erhalten → mergen. Halten Sie PRs klein, fokussiert und gut beschrieben. Branch-Schutzregeln sichern die Qualität auf main.