Lernpfad
Pull-Anfragen haben meinen Teams geholfen, Fehler zu vermeiden, sich bei Implementierungsentscheidungen abzustimmen und voneinander zu lernen. In diesem Leitfaden zeige ich dir, wie du Pull-Anfragen in Git-basierten Plattformen nutzen kannst, um deinen Code sicher zu überprüfen.
Wenn du gerade mit Git anfängst, schau dir am besten erst maldie Kurse „Einführung in Git“ und „Einführung in GitHub-Konzepte“ an, um mehr über Versionskontrolle und die Unterschiede zwischen Git und GitHub zu erfahren. Außerdem finde ich das Git-Spickzettel, das du runterladen kannst,echt hilfreich, weil es die gängigsten Git-Begriffe und -Befehle enthält.
Was ist ein Pull-Request?
Ein Pull-Request ist eigentlich eine Methode, um Änderungen am Code vorzuschlagen. Stell dir vor, du arbeitest an einer Funktion oder in einem separaten Branch. Mit einem Pull-Request kannst du darum bitten, diese Änderungen in den Haupt-Codebestand zu übernehmen. Das passiert normalerweise, nachdem andere die Möglichkeit hatten, sie zu checken. Pull-Anfragen sind ein wichtiger Teil der gemeinsamen Entwicklung, vor allem wenn man in Teams arbeitet.
Übrigens, bei GitLab heißt das Ganze „Merge Request“.
Wie funktioniert ein Pull Request?
Die folgenden Schritte zeigen den grundlegenden Ablauf eines Pull-Requests:
- Mach Änderungen am Skript (Code) in einem Feature-Zweig.
- Speicher diese Änderungen in deinem lokalen Repository.
- Schick den Branch an ein Remote-Repository wie GitHub.
- Eröffne einen Pull-Request, um die Änderungen für den Hauptzweig vorzuschlagen.
- Bitte um Überprüfung der vorgeschlagenen Änderungen.
- Je nach Ergebnis den Pull-Request zusammenführen oder schließen.
Mit diesem Workflow kann jeder Entwickler den Code checken und mögliche Probleme erkennen, bevor der Code für die Live-Produktion freigegeben wird.
Die wichtigsten Rollen im Pull-Request-Prozess sind:
- Beitragender: Der Entwickler, der Änderungen macht und den Pull-Request öffnet.
- Rezensent: Das ist der Entwickler, der die vorgeschlagenen Codeänderungen checkt, um Verbesserungen vorzuschlagen und die Codequalität sicherzustellen.
- Betreuer: Der Projektmanager, der für das Projekt verantwortlich ist und Pull-Anfragen genehmigen oder ablehnen kann.
Ich empfehle dir unseren Git-Kurs für Fortgeschrittene, um zu lernen, wie manin Git Branches erstellt und mit Teammitgliedern aus der Ferne zusammenarbeitet.
Erstellen einer Pull-Anfrage (mit Beispiel)
Angenommen, du findest einen Fehler in der ersten Zeile der README-Datei deines Projekts. Du möchtest dieses Problem beheben, ohne den Hauptzweig zu beeinträchtigen. Mach einfach Folgendes:
Schritt 1: Erstell einen neuen Zweig
Geh zum Projektordner und öffne das Terminal, um den folgenden Befehl auszuführen. Diese Zeile macht einen neuen Zweig.
git checkout -b fix-readme-typo
Schritt 2: Mach dein Kleingeld
Um die Datei zu korrigieren, öffne die Datei „ README.md
” in deinem Code-Editor, korrigiere den Tippfehler und speichere die Datei.
Schritt 3: Änderungen speichern
Stufe die Änderungen ein und speichere sie mit dem folgenden Befehl:
git add README.md
git commit -m "Fix typo in README"
Schritt 4: Zweig auf GitHub schicken
Lade den Branch ins Repo hoch.
git push origin fix-readme-typo
Schritt 5: Öffne GitHub und erstelle eine Pull-Anfrage.
Öffne jetzt dein GitHub-Konto und mach Folgendes:
-
Geh zu deinem Repository auf GitHub.
-
Wähle die Option „Vergleichen und Pull-Anfrage“ für deinen gepushten Branch aus.
-
Füge einen Titel wie „Tippfehler in README beheben“ hinzu und schreib optional eine kurze Beschreibung dazu.
-
Such dir deinen Basis-Branch aus (normalerweise „
main
“) und vergleiche ihn mit deinem Feature-Branch.
Schritt 6: Überprüfung anfordern und abschicken
Wenn andere Entwickler an deinem Projekt arbeiten, kannst du Reviewer anfordern oder Labels hinzufügen, falls das Projekt diese verwendet. Dann klick auf„ “ und „Pull-Anfrage erstellen“.
Schau dir unser Projekt „Durchführung einer Codeüberprüfung“ an, umzu erfahren, wie du Code überprüfen und ändern kannst, bevor du ihn in die Produktion überführst.
Best Practices für Pull-Anfragen
Hier sind die besten Tipps, um bei der Erstellung von Pull-Anfragen eine gute Qualität zu haben:
- Halte deine Pull-Anfragen kurz und einfach: Fang immer mit einem Pull-Request für jede Funktion an, die du vorschlagen möchtest. Das hilft dem Prüfer, deine Änderungen zu verfolgen und zu testen, und verringert die Wahrscheinlichkeit, dass ein Fehler übersehen wird.
- Schreib klare Commit-Meldungen und Beschreibungen: Schreib beschreibende Commit-Meldungen, um die Änderungen zu erklären. Dieser Kontext hilft den Reviewern, deine Absicht zu verstehen, ohne sich durch den Code wühlen zu müssen.
- Nutze Entwürfe für Pull-Anfragen, um früh Feedback zu bekommen: Wenn deine Arbeit noch nicht fertig ist, du aber schon Feedback haben möchtest, erstelle einen Entwurf für einen Pull-Request. Es zeigt an, dass dein Code noch in Arbeit ist und du gerne darüber reden kannst, ohne dass du ihn sofort zusammenführen musst.
- Teste alles gründlich und teile den Kontext mit anderen: Überprü deine Änderungen immer nochmal, um sicherzugehen, dass alles so läuft, wie du willst.
Pull-Anfragen über Git-Workflows hinweg
Hier ist ein kurzer Überblick darüber, wie verschiedene Team-Einstellungen Pull-Anfragen nutzen.
-
Feature-Verzweigung: Das ist in kleinen Teams und privaten Repositorys ganz normal. Bei diesem Arbeitsablauf wird für jede Funktion ein neuer Zweig erstellt.
-
Forking-Workflow: Dieser Arbeitsablauf wird in Open-Source-Projekten verwendet. Beim Forking-Workflow müssen Mitwirkende das Haupt-Repository in ihren Account kopieren (forken). Sie nehmen Änderungen in ihrer Fork vor und öffnen dann eine Pull-Anfrage an das Original.
-
GitFlow: Das ist ein klarer Arbeitsablauf, der langfristige Zweige wie „
main
“, „develop
“, „release
“ und „hotfix
“ nutzt. Es wird von größeren Teams mit komplexeren Release-Zyklen verwendet.
Pull-Request-Etikette
Es kann schon mal was schiefgehen, deshalb gibt's für Pull-Anfragen eine Art Etikette:
- Sei respektvoll und konkret: Konzentrier dich auf den Code, nicht auf die Person.
- Halte Pull-Anfragen auf den Punkt: Vermeide es, nicht zusammenhängende Änderungen in einem Pull-Request zu mischen. Das macht die Überprüfung und das Feedback nur komplizierter.
- Reagier gut auf Feedback: Loben Sie gut geschriebenen Code und Verbesserungsvorschläge.
- Lass Pull-Anfragen nicht zu lange liegen: Versuche immer, Pull-Anfragen so schnell wie möglich zu prüfen und zu bearbeiten, um Verzögerungen bei Updates zu vermeiden.
- Frag einfach rein: Wenn dir was nicht klar ist, frag lieber nach, anstatt einfach anzunehmen, dass jemand was Bestimmtes will. So vermeidest du Missverständnisse.
- Verbesserungsvorschläge: Wenn es passt, gib lieber praktische Tipps oder alternative Ansätze, anstatt nur Probleme aufzuzeigen.
Erweiterte Pull-Request-Workflows und Best Practices
Wenn du ein erfahrener Entwickler bist und die Zusammenarbeit reibungsloser gestalten, die Codequalität verbessern und deinen Pull-Request-Prozess skalieren möchtest, findest du hier ein paar praktische Tipps, um deinen Workflow zu optimieren.
Bessere Arbeitsabläufe
Verschiedene Git-Workflows gehen mit Pull-Anfragen unterschiedlich um. Wie wir schon gesagt haben, ist Feature-Branching wegen seiner Einfachheit super für kleine Teams. Allerdings kann es schwierig werden, das zu schaffen, wenn dein Team wächst.
Forking ist für Open-Source-Projekte empfehlenswert, kann aber zu mehr Aufwand bei der Synchronisierung und Überprüfung externer Beiträge führen. Gleichfalls ist GitFlow für schnelle Entwicklungen empfehlenswert, auch wenn es wegen seiner Komplexität den Prozess verlangsamen kann.
Automatisierung und Integration
Moderne Pull-Anfragen haben CI/CD-Checks, die Qualitätskontrollen automatisch machen, indem sie Tools für die kontinuierliche Integration einbauen, die Tests und Linter ausführen und bei jeder PR eine Vorschau bereitstellen. Dadurch wird sichergestellt, dass nur Code zusammengeführt wird, der die festgelegten Standards erfüllt.
Plattformen wie GitHub Actions und GitLab Pipelines machen auch Automatisierung möglich. Dazu gehören das Ausführen von Unit-Tests, das Erstellen und Bereitstellen von Vorschauumgebungen, das Reduzieren von manuellen Schritten und das frühzeitige Erkennen von Problemen.
Bewertungen optimieren
Halte Pull-Anfragen immer kurz und auf das Wesentliche beschränkt, damit sie schnell und gründlich geprüft werden können. Mit Vorlagen, die übersichtliche Felder wie „Was hat sich geändert?“ und „Wie kann man das testen?“ haben, können Leute, die was beitragen, prägnante und relevante Infos liefern, was die Überprüfungen effizienter macht.
Du solltest auch bedenken, dass Fragen stellen statt Forderungen stellen einen guten Dialog und das Lernen fördern. Wenn du Bearbeitungszeiten für Überprüfungen festlegst, bleibt der Prozess planbar und du vermeidest Verzögerungen.
Metriken und moderne Tools
Ich empfehle dir auch, die Größe der PRs, die Zeit für die Überprüfung und die Merge-Rate im Lernpfad zu verfolgen, um Engpässe zu erkennen und den Workflow effizienter zu gestalten. Um das Überprüfen und Zusammenführen einfacher zu machen, probier mal einen gestapelten Pull-Request aus. Dadurch würden große Features in kleinere, miteinander verbundene PRs aufgeteilt, die aufeinander aufbauen.
Außerdem kannst du KI-Tools wie GitHub Copilot oder CodeWhisperer integrieren, wenn du Pull-Anfragen verwendest. Mit diesen Tools kannst du mögliche Probleme frühzeitig erkennen und Lösungen vorschlagen.
Pull-Anfragen vs. Anfragen zusammenführen
In GitHub und GitLab werden Pull Requests (PR) und Merge Requests (MR) gleich verwendet. Obwohl sie denselben Zweck erfüllen, werden sie von jeder Plattform anders gehandhabt.
Die Tabelle unten zeigt die Unterschiede zwischen PRs und MRs.
Aspekt |
Pull-Anfrage (GitHub) |
Zusammenführungsanfrage (GitLab) |
Begriffe |
Änderungen abrufen |
Änderungen zusammenführen |
Hauptverwendung |
Code-Änderungen vorschlagen, überprüfen und zusammenführen |
Code-Änderungen vorschlagen, überprüfen und zusammenführen |
Typische Nutzer |
Open-Source-Entwickler, kleine bis mittlere Teams |
DevOps-lastige Teams, Unternehmen und private Repositorys |
CI/CD-Integration |
GitHub-Aktionen (optional, muss eingerichtet werden) |
Integrierte CI/CD standardmäßig |
Entwurf Unterstützung |
Native Unterstützung für Draft PRs |
Unterstützt durch das Label „Entwurf“ oder die Präfixe WIP |
Genehmigungen zusammenführen |
Grundlegende Einstellungen für Prüfer und Genehmigungen |
Erweiterte Regeln: mehrere Genehmigende, Genehmigungsabläufe |
Strategien zusammenführen |
Commits zusammenführen, zusammenfassen oder neu basieren |
Ähnliche Optionen, mit einstellbaren Einschränkungen für die Zusammenführungsmethode |
Workflow-Philosophie |
Entwicklerorientiert, flexibel |
DevOps-fokussiert, mit enger Integration zwischen Entwicklung und Betrieb |
Fazit
Pull-Anfragen sind ein Muss für jedes ernsthafte Projekt. Wie du gesehen hast (und hoffentlich jetzt auch verstehst), können Teams damit gemeinsam Code überprüfen, besprechen und verbessern.
Mach weiter so und verbessere deine Fähigkeiten als Entwickler. Schau dir unsere Lernpfade „Git-Grundlagen“ und „GitHub-Grundlagen“ an, um ein echter Git-Profi zu werden.
Lerne heute die Git-Grundlagen
Häufig gestellte Fragen zu Pull-Anfragen
Ist ein Pull-Request dasselbe wie ein Merge-Request?
GitHub nennt das einen „Pull Request“, während GitLab den Begriff „Merge Request“ verwendet, aber beide machen dasselbe.
Kann ich Änderungen an einem Pull-Request vornehmen, nachdem ich ihn geöffnet habe?
Ja, wenn du neue Commits in denselben Branch schickst, wird der Pull Request automatisch aktualisiert.
Kann ich einen Branch löschen, nachdem ich einen Pull Request zusammengeführt habe?
Ja, es ist besser, den Branch nach dem Zusammenführen des Pull-Requests zu löschen, damit dein Repository ordentlich bleibt.
Was ist ein Entwurf für eine Pull-Anfrage?
Ein Entwurf für einen Pull-Request ist ein Pull-Request, an dem noch gearbeitet wird. Du kannst es verwenden, wenn du noch nicht bereit bist, zu fusionieren, aber frühzeitig Feedback haben möchtest.
Was ist der Unterschied zwischen einem Pull-Request und einem Branch?
Ein Branch ist sozusagen ein eigener Entwicklungszweig, während ein Pull-Request ein offizieller Vorschlag ist, die Änderungen aus diesem Branch in einen anderen Branch zu übernehmen.