Was ist ein Pull Request?

Ein Pull Request (PR) ist eine Methode, um Änderungen an einer Codebasis vorzuschlagen. Softwareentwickler verzweigen das Haupt-Code-Repository (auch „Repo“ genannt) in einen separaten Zweig, übertragen im Laufe ihrer Arbeit Code in diesen Zweig und erstellen einen Pull-Request, um ihre vorgeschlagenen Änderungen zur Codeüberprüfung zu kennzeichnen, bevor sie die Änderungen aus dem Zweig in die Haupt-Codebasis übernehmen oder zusammenführen.

PRs sind gängige Mechanismen in Git-Repositories wie Bitbucket und GitHub. GitLab verwendet für denselben Vorgang den Begriff „Merge Request“ anstelle von „Pull Request“.

Entwickler können Pull Requests über die Befehlszeilenschnittstelle (CLI) oder die Weboberfläche erstellen. Neue Pull Requests werden typischerweise für Fixes, Abhängigkeitsupdates, neue Funktion oder refactorierten Code geöffnet. Pull Requests optimieren Code-Reviews, halten Codebasen auf dem neuesten Stand und fördern die Zusammenarbeit zwischen Mitgliedern von Softwareentwicklungsteams.

PRs ermöglichen es Entwicklern, Quellcode zu erstellen und ihn lokal zu testen. Da Codeänderungen vom Hauptzweig isoliert sind, müssen sich Entwickler keine Sorgen machen, dass sie die gesamte Codebasis beeinträchtigen könnten.

Die Pull-Request-Methodik umfasst drei wichtige Aufgaben, die hauptsächlich auf Open-Source-Projekte angewendet werden, aber auch von proprietären oder Closed-Source-Projekten übernommen werden können:

• Maintainer: Projektbetreuer verwalten (und besitzen oft) das Projekt und haben die Befugnis, PRs zu genehmigen und zusammenzuführen oder sie abzulehnen.

• Begutachter: Diese Teammitglieder (die selbst Maintainer oder andere aktive Mitwirkende mit viel Projekterfahrung sein können) prüfen vorgeschlagene Änderungen hinsichtlich der Codequalität und schlagen Verbesserungen vor, wie sie es für richtig halten.

• Mitwirkende: Diese Entwickler sind dafür zuständig, Änderungen vorzunehmen und Pull-Anfragen zu öffnen.

Das Erstellen von Pull-Anfragen umfasst in der Regel einen siebenstufigen Prozess:

1. Ein Mitwirkender forkt das Hauptrepository, um einen neuen Branch zu erstellen (unter Verwendung der git checkout Befehl oder die Weboberfläche) und klont diesen Zweig auf ihre lokale Maschine.
   
   
2. Der Mitwirkende arbeitet an seinen Änderungen und überträgt den Code lokal in den Zweig.
   
   
3. Sobald der Beitragende seinen Code fertiggestellt und getestet hat, zieht er zunächst die neuesten Updates aus dem Haupt-Repository, um widersprüchliche Änderungen zu vermeiden, bevor er seinen Code veröffentlicht.
   
   
4. Der Mitwirkende öffnet eine neue Pull-Anfrage für seine vorgeschlagenen Änderungen, die in den Hauptzweig integriert werden sollen.
   
   
5. Gutachter erhalten Benachrichtigungen, wenn Pull Requests eingereicht werden. Sie überprüfen die PR, um die Unterschiede (auch als „Diffs“ bezeichnet) zwischen dem Treiber-Branch und dem Haupt-Branch zu vergleichen, überprüfen den Code und kommentieren Bereiche, die optimiert oder verbessert werden müssen.
   
   
6. Die Mitwirkenden machen zusätzliche Übertragungen auf der Grundlage der Vorschläge und Änderungswünsche der Prüfer.
   
   
7. Wenn alle Änderungen umgesetzt wurden, benachrichtigt der Prüfer den Maintainer, der den PR genehmigt. Der Pull-Request wird dann mit dem Haupt-Repository zusammengeführt.

Softwareentwicklungsteams können je nach Bedarf aus verschiedenen PR-Workflow-Optionen wählen. Gängige Pull-Request-Workflows sind:

• Workflow für Feature-Branches

• Forking Workflow

• Git-Flow

• Stacked Workflow

Jede neue Funktion erhält einen eigenen Branch mit einem aussagekräftigen Namen, der den Zweck der Funktion verdeutlicht. Sobald die Funktion fertiggestellt ist, können Entwickler den Feature-Zweig in den Hauptzweig übernehmen und einen Pull-Request erstellen.

Dieser Workflow gewährleistet die Stabilität des Hauptzweigs, während die Mitwirkenden unabhängig voneinander an neuen Funktionen arbeiten. Die Verwaltung mehrerer Feature-Branches kann jedoch unübersichtlich werden.

Das im vorigen Abschnitt beschriebene siebenstufige Verfahren zum Erstellen von Pull-Anfragen entspricht einem Forking Workflow. Open-Source-Projekte nutzen häufig diesen Arbeitsablauf, der zudem die Praktiken der kontinuierlichen Integration/kontinuierlichen Bereitstellung (CI/CD) ergänzt. Der GitHub-Workflow folgt einem ähnlichen Prozess wie der Forking-Workflow.

Der Softwareingenieur Vincent Driessen entwickelte Git-Flow im Jahr 2010. Es wird typischerweise für die Entwicklung von Software mit strengen Release-Zyklen oder für solche, die verschiedene Versionen unterstützen, verwendet.

Dieser Workflow folgt einem Verzweigungsmodell, das aus diesen Zweigen besteht:

• main enthält die neueste stabile Version

• develop dient als Integration für Fixes, Funktion und andere Codeänderungen, die in der nächsten Version enthalten sind

• feature verwendet den Entwicklungszweig als Quell- und Zielzweig; Funktionen werden in den Entwicklungszweig integriert, sobald sie fertig sind.

• release wird aus dem „develop“-Zweig abzweigt und mit der Versionsnummer der nächsten Veröffentlichung versehen; sobald es veröffentlichungsreif ist, wird es sowohl in den „develop“- als auch in den „main“-Zweig integriert

• hotfix wird direkt aus dem „main“-Zweig abgezweigt, um alle Produktionsprobleme mit hoher Priorität oder hohem Schweregrad zu beheben, und anschließend in den „develop“- und den „main“-Zweig zusammengeführt, sobald die Fehlerbehebung abgeschlossen ist

Entwickler erstellen Pull-Anfragen für die Branches hotfix, feature und release, die überprüft werden müssen.

Ein Stacked Workflow zerlegt große Aufgaben in eine Reihe kleiner, schrittweisen Codeänderungen. Die nächste Codeänderung hängt von der vorherigen ab, sodass Pull Requests aufeinander aufgebaut werden.

Betrachten Sie eine Funktion, die Änderungen an folgenden Komponenten beinhaltet: der Datenbank oder dem Datenmodell, der API und dem Frontend. Beim herkömmlichen Feature-Branch- oder Forking-Workflow muss ein Mitwirkender warten, bis der Pull-Request für die Änderungen an der Datenbank oder am Datenmodell geprüft, genehmigt und in den Hauptzweig integriert wurde, bevor er mit den API-Aktualisierungen beginnen kann. Bei einem gestapelten Workflow entfällt diese Wartezeit – der Mitwirkende kann von den Datenbank- oder Datenmodelländerungen abzweigen, um mit der Arbeit an der API zu beginnen, absenden einen Pull Request dafür und die API-Änderungen abzweigen, um Frontend-Aufgaben anzugehen.

Pull Requests bieten folgende Vorteile:

• Kultiviert die Zusammenarbeit

• Verbessern die Codequalität

• Steigert die Transparenz

• Stärkt die Programmierkenntnisse

Pull Requests fördern die Zusammenarbeit und ermutigen die Teammitglieder, unabhängig von ihrer Rolle zusammenzuarbeiten. PRs erleichtern das Feedback und den Umgang damit, stoßen Diskussionen an und lösen Ideen für Verbesserungen aus.

PRs starten den Code-Review-Prozess und helfen dabei, Fehler, Abweichungen vom Codierung und den Standards, Leistungsprobleme und Sicherheitslücken zu lokalisieren. Durch diese zusätzliche Aufsicht wird die Qualität des Codes aufrechterhalten oder sogar verbessert.

Mithilfe von Pull Requests können Teams sehen, welche Änderungen implementiert wurden, wer sie vorgenommen hat, wo sie angewendet wurden und die Gründe dafür. Diese Transparenz bietet eine bessere Erkenntnis in den Zustand der Codebasis und des Projekts selbst.

Sowohl Rezensenten als auch Autoren können voneinander lernen, dabei neue Techniken erlernen und neuartige Lösungsansätze für Probleme. Anfänger und neue Teammitglieder können auch frühere PRs studieren, um den Code besser zu verstehen und sich mit den Coding-Standards und Best Practices des Teams vertraut zu machen.

Das Erstellen von Pull-Requests scheint zwar einfach zu sein, aber hier sind einige Tipps und Tricks, die den Prozess weiter vereinfachen können:

• Betrachten Sie Entwürfe

• Details sind wichtig

• Fokus behalten

• Bleiben Sie auf dem neuesten Stand

• Vorlagen aufnehmen

Entwürfe für Pull Requests oder Merge Requests dienen Entwicklern als Avenue, ihre laufende Arbeit zu teilen. Dadurch können Teammitglieder früher mit der Zusammenarbeit beginnen und frühzeitig Feedback einholen, sodass diejenigen, die bei einem Problem nicht weiterkommen, mögliche Lösungen von ihren Teamkollegen einholen können.

Entwickler müssen klare, prägnante und spezifische Meldungen für ihre neuen Commits bereitstellen. Klarheit, Prägnanz und Spezifität gelten auch für PR-Titel und -Beschreibungen, damit Prüfer die Absicht hinter den Codeänderungen leichter und schneller erfassen können.

Die Bündelung mehrerer Themen in einem einzigen PR kann zu längeren Überprüfungszeiten und mehr Revisionen führen. Jeder Pull-Request darf nur eine Adresse für einen Bugfix oder eine Funktion haben. Gezielte Pull-Requests können zu effizienteren Code-Reviews führen.

Bevor Entwickler Code hochladen und einen Pull Request öffnen, müssen sie sicherstellen, dass ihr Branch auf dem neuesten Stand ist. Das Übernehmen der neuesten Änderungen und aller neuen Commits verhindert Konflikte, sobald die Pull-Anfrage zusammengeführt wurde. Sie können entweder den Befehl git pull verwenden, um Änderungen aus dem Zielzweig zu holen und zusammenzuführen, oder den Befehl git rebase für einen sauberen Git-Commit-Verlauf.

Vorlagen für PR-Beschreibungen sorgen für Konsistenz und bieten wichtigen Kontext, um reviews zu optimieren. Teams können eine Vorlage für verschiedene Pull-Request-Typen erstellen, z. B. für Fixes, Funktionen oder refaktorierten Code.

Templates werden üblicherweise mit der Markdown-Markup-Sprache geschrieben und im Root-Ordner oder im Hauptzweig des Projekt-Repo platziert. Typische Felder sind:

• Problem- oder Feature-Beschreibung (mit einem Link zum entsprechenden Ticket in Jira oder anderer Issue-Tracking-Software zur Referenz)

• Lösung, die Codeänderungen detailliert skizziert

• Tests, wie Unit-Test- oder Integrationstestfälle , Testabdeckung und Schritte zur manuellen Validierung der Lösung, falls anwendbar,

• Konfigurationsänderungen

• Checkliste relevanter Aufgaben, wie Dokumentation und saubere Code-Builds ohne Fehler oder Warnungen

Die Automatisierung von PRs kann den Lebenszyklus eines Pull-Requests von der Erstellung über die reviews bis hin zum Zusammenführen beschleunigen. PR-Automatisierung umfasst eine Ebene von Systemen, die helfen, Engpässe zu verringern:

• Gestapelte PRs

• CI/CD-Pipelines

• SDLC-Managementsysteme

• KI-gestützte Codierungsassistenten

Die meisten Git-Repositories sind nicht für die Unterstützung eines gestapelten Workflows ausgelegt, aber einige Tools abstrahieren die Komplexität der Synchronisierung gestapelter Pull Requests und der Behandlung von Merge-Konflikten. Zu diesen Tools gehören die Graphite-Plattform, die eine CLI und eine Erweiterung für Microsofts VS Code für gestapelte PRs sowie eine Weboberfläche zur Verwaltung bietet; Metas Quellcode-Managementsystem Sapling; und die Open-Source-CLI ghstack zum Einreichen gestapelter Diffs als separate Pull Requests an GitHub.

Als automatisierter DevOps-Workflow trägt die CI/CD-Pipeline zur Sicherstellung der Codequalität bei. Plattformen wie GitHub Actions und GitLab und andere CI-Tools können Unit-Tests und Integration-Tests durchführen und Vorschauumgebungen bereitstellen, die als Sandbox dienen, um Codeänderungen in PRs anzuzeigen und zu testen.

CI/CD-Pipelines verstärken zudem sichere Codierung . Statische Code-Analysatoren und andere statische Anwendungssicherheitstests (SAST) lassen sich nahtlos in die meisten CI/CD-Umgebungen integrieren, um wahrscheinliche Code-Schwachstellen zu identifizieren. DevOps-Teams können Pre-Commit-Hooks zur Geheimniserkennung implementieren, wodurch das Scannen von Geheimnissen ein Pflichtschritt wird, bevor Entwickler Code committen oder Pull Requests starten, und Änderungen blockieren, die fest kodierte Geheimnisse enthalten.

Plattformen wie Jira und IBM® Engineering Lifecycle Management (ELM) unterstützen die Nachverfolgung und Verwaltung von Pull Requests während des gesamten Softwareentwicklungslebenszyklus (SDLC).

Als Teil der ELM-Suite betten IBM Engineering Workflow Management (EWM) und IBM Engineering Integration Hub die PR-Automatisierung direkt in die Entwicklungs-Workflows ein. EWM kann über die Konnektoren des Hubs eine Verbindung zu Git-Repositories herstellen und die Erstellung von Pull Requests aus Arbeitselementen auslösen. Wenn eine Anforderung oder Änderungsanfrage in EWM genehmigt wird, kann eine Regel automatisch eine Pull-Anfrage im verknüpften Git-Repository öffnen und die Beschreibung vorausfüllen.

Al-gesteuerte Automatisierungen in ELM können auch statische Analysen und Suite ausführen, sobald die PR geöffnet ist, die Ergebnisse an das Arbeitselement zurückposten und die Zusammenführung blockieren, bis die Kriterien erfüllt sind. In der Zwischenzeit synchronisiert der Hub den PR-Status toolübergreifend und spiegelt ihn im Repository und in den EWM-Dashboards wider, sodass er in Echtzeit sichtbar ist.

KI-gestützte Codierassistenten wie GitHub Copilot und IBM Bob können Pull-Request-Workflows ergänzen. Zum Beispiel kann Bob gut formatierte, aussagekräftige Commit-Nachrichten generieren. Es prüft den Branchnamen und die Commit-Historie, um sicherzustellen, dass sie den Stilkonventionen des Projekts entsprechen.

Bob kann auch direkt aus der Entwickler-IDE heraus einen Pull Request erstellen. Es analysiert den Branchnamen, die Codeänderungen und die Commit-Historie, um Zweck und Umfang zu verstehen. Anschließend wird ein PR-Titel und eine detaillierte Beschreibung generiert, die die Änderungen zusammenfasst. Dabei werden automatisch die vorhandenen PR-Vorlagen eines Projekts für Pull-Request-Beschreibungen erkannt und verwendet.