Einen Pull Request erstellen
Pull requests are a feature that makes it easier for developers to collaborate using Bitbucket. They provide a user-friendly web interface for discussing proposed changes before integrating them into the official project.
Mit der einfachsten Form von Pull-Requests können Entwickler anderen Teammitgliedern mitteilen, dass sie ein Feature fertiggestellt haben. Sobald ein Feature-Branch fertig ist, übermittelt der Entwickler einen Pull-Request über seinen Bitbucket-Account. So werden alle Beteiligten darüber informiert, dass sie den Code prüfen und in den main-Branch mergen müssen.
Pull-Requests sind jedoch mehr als bloße Benachrichtigungen – sie bieten ein dediziertes Forum zur Besprechung eines vorgeschlagenen Features. Sollten Probleme bei den Änderungen auftreten, können Teamkollegen im Pull-Request Feedback geben und das Feature sogar nachjustieren, indem sie nachfolgende Commits pushen. All diese Aktivitäten werden direkt im Pull-Request verfolgt.
Im Vergleich zu anderen Zusammenarbeitsmodellen sorgt diese formale Lösung zum Teilen von Commits für einen erheblich strafferen Workflow. SVN und Git sind beide in der Lage, automatische Benachrichtigungs-E-Mails mit einem simplen Skript zu senden. Bei der Besprechung von Änderungen müssen die Entwickler jedoch normalerweise auf E-Mail-Ketten zurückgreifen. Dies wird schnell unübersichtlich, insbesondere wenn nachfolgende Commits hinzukommen. Pull-Requests bieten dir all diese Funktionen in einer angenehmen Web-Oberfläche direkt neben deinen Bitbucket-Repositorys.
Anatomie eines Pull-Requests
Mit einem Pull-Request sendest du im Prinzip eine Anfrage (Englisch request) an einen anderen Entwickler (z. B. den Projektwartenden), der einen Branch aus deinem Repository in sein Repository ziehen (Englisch to pull) soll. Du musst daher in einem Pull-Request vier Angaben machen: Quell-Repository und Quell-Branch sowie Ziel-Repository und Ziel-Branch.
Viele dieser Werte sind in Bitbucket auf einen zweckmäßigen Standardwert voreingestellt. Je nach Zusammenarbeits-Workflow benötigt dein Team jedoch möglicherweise andere Werte. Das obige Diagramm zeigt einen Pull-Request, der das Mergen eines Feature-Branch in den offiziellen Haupt-Branch anfragt. Pull-Requests lassen sich aber auch auf viele andere Weisen nutzen.
Wie funktioniert "git revert"?
Pull-Requests können in Verbindung mit dem Feature Branch Workflow, dem Git-flow-Workflow oder dem Forking-Workflow eingesetzt werden. Da für Pull-Requests entweder zwei verschiedene Branches oder zwei verschiedene Repositorys erforderlich sind, eignen sie sich nicht für den zentralisierten Workflow. Die genaue Verwendung der Pull-Requests ist bei den verschiedenen Workflows etwas unterschiedlich, folgt jedoch einem grundlegenden Prozess:
1. Der Entwickler arbeitet in einem dedizierten Branch in seinem lokalen Repository am Feature.
2. The developer pushes the branch to a public Bitbucket repository.
3. The developer files a pull request via Bitbucket.
4. The rest of the team reviews the code, discusses it, and alters it.
5. The project maintainer merges the feature into the official repository and closes the pull request.
Die folgenden Abschnitte drehen sich darum, wie Pull-Requests im Rahmen der verschiedenen Zusammenarbeits-Workflows funktionieren.
Zugehöriges Material
Git-Protokoll für Fortgeschrittene
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
Feature Branch Workflow mit Pull-Requests
Beim Feature-Branch-Workflow wird die Zusammenarbeit über ein gemeinsames Bitbucket-Repository verwaltet und die Entwickler erstellen Features in isolierten Branches. Die Features sollten nicht sofort in den main-Branch gemergt werden. Stattdessen sollten die Entwickler einen Pull-Request erstellen, um das Feature zu besprechen, bevor es in die Haupt-Codebasis aufgenommen wird.
Da beim Feature-Branch-Workflow nur ein einziges öffentliches Repository vorhanden ist, sind das Quell- und das Ziel-Repository im Pull-Request immer identisch. In der Regel gibt der Entwickler seinen Feature-Branch als Quell-Branch und den main-Branch als Ziel-Branch an.
Wenn der Projekt-Mainainer den Pull-Request erhalten hat, muss er über das weitere Vorgehen entscheiden. Ist das Feature schon einsatzbereit, kann er es einfach in den main-Branch mergen und den Pull-Request abschließen. Falls jedoch ein Problem mit den vorgeschlagenen Änderungen besteht, kann der Projekt-Maintainer im Pull-Request entsprechendes Feedback abgeben. Die nachfolgenden Commits werden direkt neben den relevanten Kommentaren angezeigt.
Es ist auch möglich, einen Pull-Request für ein unfertiges Feature zu übermitteln. Wenn ein Entwickler beispielsweise Probleme bei der Implementierung einer bestimmten Anforderung hat, kann er einen Pull-Request mit seiner WIP-Aufgabe übermitteln. Nun können andere Entwickler direkt im Pull-Request Vorschläge machen oder sogar das Problem selbst mit zusätzlichen Commits lösen.
Git-flow-Workflow mit Pull-Requests
Der Git-flow-Workflow ist dem Feature Branch Workflow ähnlich, aber er definiert ein strenges Branching-Modell, das um den Release des Projekts konzipiert wurde. Durch die Ergänzung des Git-flow-Workflows durch Pull-Requests wird den Entwicklern ein geeigneter Ort zur Diskussion über einen Release Branch oder Maintenance Branch bereitgestellt, während sie an ihm arbeiten.
Der Mechanismus der Pull-Requests im Git-flow-Workflow unterscheidet sich nicht von dem zuvor beschriebenen Ablauf: Ein Entwickler übermittelt einfach einen Pull-Request, wenn ein Feature, Release oder Hotfix Branch überprüft werden muss, und das übrige Team wird über Bitbucket darüber informiert.
Generell werden Features in den develop-Branch gemergt, während Release- und Hotfix-Branches in den develop-Branch und in den main-Branch gemergt werden. Alle diese Merge-Vorgänge lassen sich mithilfe von Pull-Requests formell verwalten.
Forking Workflow mit Pull-Requests
Beim Forking-Workflow verschiebt der Entwickler sein fertiges Feature in ein eigenes (d. h. kein gemeinsam genutztes) öffentliches Repository. Dann übermittelt er einen Pull-Request, um dem Projektwartenden mitzuteilen, dass das Feature zum Review bereit ist.
Die Benachrichtigungen zu Pull-Requests sind in diesem Workflow ganz besonders hilfreich, da der Projekt-Maintainer nicht wissen kann, wann ein anderer Entwickler dem Bitbucket-Repository Commits hinzugefügt hat.
Da jeder Entwickler ein eigenes öffentliches Repository besitzt, ist im Pull-Request das Quell-Repository nicht identisch mit dem Ziel-Repository. Das öffentliche Repository des Entwicklers ist das Quell-Repository und das Repository mit den Änderungsvorschlägen ist der Quell-Branch. Wenn der Entwickler das Feature in die Haupt-Codebasis mergen will, ist das offizielle Projekt das Ziel-Repository und der main-Branch der Ziel-Branch.
Pull-Requests können auch zur Zusammenarbeit mit Entwicklern außerhalb des offiziellen Projekts genutzt werden. Wenn beispielsweise ein Entwickler mit einem Teamkollegen an einem Feature arbeitet, könnte er einen Pull-Request übermitteln, in dem als Ziel das Bitbucket-Repository des Teamkollegen statt des offiziellen Projekts angegeben ist. Als Quell- und Ziel-Branch würde in diesem Fall derselbe Feature Branch dienen.
Die beiden Entwickler können das Feature innerhalb des Pull-Requests diskutieren und ausarbeiten. Ist es fertiggestellt, setzt einer von ihnen einen Pull-Request ab, damit das Feature in den offiziellen Haupt-Branch gemergt wird. Diese Flexibilität macht Pull-Requests zu einem enorm leistungsstarken Zusammenarbeitstool im Rahmen des Forking-Workflows.
Beispiel
Im folgenden Beispiel wird gezeigt, wie Pull-Requests im Forking Workflow verwendet werden können. Es ist gleichermaßen anwendbar auf Entwickler, die in einem kleinen Team arbeiten, und auf Dritt-Entwickler, die sich an einem Open-Source-Projekt beteiligen.
In diesem Beispiel ist Mary eine Entwicklerin und John der Projekt-Maintainer. Beide haben ihre eigenen öffentlichen Bitbucket-Repositorys, das von John enthält das offizielle Projekt.
Mary forkt das offizielle Projekt
Um ihre Arbeit am Projekt beginnen zu können, muss Mary zunächst Johns Bitbucket-Repository forken. Hierzu meldet sie sich bei Bitbucket an, navigiert zu Johns Repository und klickt auf die Schaltfläche Forken.
Nach der Eingabe des Namens und der Beschreibung des geforkten Repositorys verfügt sie über eine serverseitige Kopie des Projekts.
Mary klont ihr Bitbucket-Repository
Als Nächstes muss Mary das soeben geforkte Bitbucket-Repository klonen, um auf ihrem lokalen Rechner eine Arbeitskopie des Projekts zu erhalten. Hierfür gibt sie den folgenden Befehl ein:
git clone https://user@bitbucket.org/user/repo.gitBeachte, dass mit git clone automatisch eine origin-Remote-Verbindung hergestellt wird, die zurück auf Marys geforktes Repository verweist.
Mary entwickelt ein neues Feature
Bevor Mary mit dem Schreiben von Code beginnt, muss Mary zunächst einen neuen Branch für das Feature erstellen. Diesen Branch wird sie als Quell-Branch des Pull-Requests verwenden.
git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"Zum Erstellen des Features kann Mary so viele Commits wie nötig nutzen. Wenn der Verlauf des Features zu unübersichtlich wird, kann sie durch ein interaktives Rebasing überflüssige Commits entfernen oder squashen. Bei größeren Projekten hilft das Bereinigen des Feature-Verlaufs dem Projektwartenden, den Überblick über den aktuellen Stand des Pull-Requests zu behalten.
Mary pusht das Feature in ihr Bitbucket-Repository
Sobald das Feature fertig ist, verschiebt Mary den Feature Branch mit einem simplen git push in ihr eigenes Bitbucket-Repository (nicht in das offizielle Repository):
git push origin some-branchNun kann der Projekt-Maintainer (oder bei Bedarf auch ein anderer Mitarbeiter) auf ihre Änderungen zugreifen.
Mary erstellt den Pull-Request
Nach der Übermittlung des Feature Branch an Bitbucket kann Mary den Pull-Request über ihren Bitbucket-Account erstellen. Dazu navigiert sie zu ihrem geforkten Repository und klickt in der oberen rechten Ecke auf die Schaltfläche Pull-Request. Im daraufhin erstellten Formular wird Marys Repository automatisch als Quell-Repository eingetragen. Sie muss noch den Quell-Branch, das Ziel-Repository und den Ziel-Branch angeben.
Mary möchte ihr Feature in die Haupt-Codebasis mergen. Also ist ihr Feature-Branch der Quell-Branch, Johns öffentliches Repository ist das Ziel-Repository und main ist der Ziel-Branch. Sie muss im Pull-Request auch einen Titel und eine Beschreibung angeben. Wenn außer John noch weitere Personen den Code genehmigen müssen, kann Mary diese Personen im Feld Reviewer eingeben.
Nach dem Erstellen des Pull-Requests erhält John eine Benachrichtigung in seinem Bitbucket-Feed und (optional) per E-Mail.
John überprüft den Pull-Request
John kann auf alle übermittelten Pull-Requests zugreifen, indem er in seinem eigenen Bitbucket-Repository auf die Registerkarte Pull-Request klickt. Wenn er auf Marys Pull-Request klickt, werden eine Beschreibung des Pull-Requests, der Commit-Verlauf des Features und ein Diff aller enthaltenen Änderungen angezeigt.
Wenn John der Meinung ist, das Feature könne in das Projekt gemergt werden, muss er nur auf die Schaltfläche Merge durchführen klicken, um den Pull-Request zu genehmigen und Marys Feature in seinen main-Branch zu mergen.
Aber nehmen wir in diesem Beispiel einmal an, dass John einen kleinen Fehler in Marys Code gefunden hat, den sie vor dem Merge beheben muss. Er kann entweder im gesamten Pull-Request einen Kommentar hinterlassen oder einen bestimmten Commit im Feature-Verlauf auswählen und diesen kommentieren.
Mary fügt einen nachfolgenden Commit hinzu
Wenn Mary Fragen zu diesem Feedback haben sollte, kann sie innerhalb des Pull-Requests reagieren und quasi ein Diskussionsforum zu ihrem Feature eröffnen.
Um ihren Fehler zu beheben, fügt Mary ihrem Feature Branch einen weiteren Commit hinzu und verschiebt ihn genauso wie zuvor auch in ihr Bitbucket-Repository. Dieser Commit wird dem ursprünglichen Pull-Request automatisch hinzugefügt und John kann die Änderungen direkt neben seinem vorherigen Kommentar erneut prüfen.
John akzeptiert den Pull-Request
Abschließend nimmt John die Änderungen an, mergt den Feature-Branch in den Haupt-Branch und schließt den Pull-Request. Das Feature ist jetzt in das Projekt integriert, d. h., alle anderen daran arbeitenden Entwickler können es mit dem üblichen git pull-Befehl in ihre eigenen lokalen Repositorys übernehmen.
Wie geht es weiter?
Du solltest jetzt alles haben, was du zum Integrieren von Pull-Requests in deinen bestehenden Workflow benötigst. Zur Erinnerung: Pull-Requests sind kein Ersatz für die Git-basierten Workflows zur Zusammenarbeit, sondern eher eine praktische Ergänzung dazu, die allen Teammitgliedern die Zusammenarbeit erleichtert.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
