Making a pull request

Einen Pull Request erstellen

Pull-Requests erleichtern Entwicklern die Zusammenarbeit in Bitbucket. Die Entwickler können Änderungsvorschläge über eine benutzerfreundliche Weboberfläche diskutieren, bevor sie in das offizielle Projekt eingearbeitet werden.

Git Workflows: Pull Request in Bitbucket

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 sein Bitbucket-Konto. So werden alle Beteiligten darüber informiert, dass sie den Code prüfen und in den master-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.

Git Workflows: Activity inside a pull request

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 Projekt-Maintainer), 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.

Git Workflows: Pull Requests

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 Master-Branch anfragt. Pull-Requests lassen sich aber auch auf viele andere Weisen nutzen.

Wie es funktioniert

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. Der Entwickler verschiebt den Branch in ein öffentliches Bitbucket-Repository.

  3. Der Entwickler übermittelt einen Pull-Request über Bitbucket.

  4. Der Rest des Teams überprüft den Code, diskutiert darüber und modifiziert ihn.

  5. Der Projekt-Maintainer mergt das Feature in das offizielle Repository und schließt den Pull-Request.

Die folgenden Abschnitte drehen sich darum, wie Pull-Requests im Rahmen der verschiedenen Zusammenarbeits-Workflows funktionieren.

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 master-Branch gemergt werden. Stattdessen sollten die Entwickler einen Pull-Request erstellen, um das Feature zu besprechen, bevor es in die Haupt-Codebasis aufgenommen wird.

Pull Request: Feature Branch workflow

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 master-Branch als Ziel-Branch an.

Wenn der Projekt-Maintainer den Pull-Request erhalten hat, muss er über das weitere Vorgehen entscheiden. Ist das Feature schon einsatzbereit, kann er es einfach in den master-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 Wartungs-Branch bereitgestellt, während sie an ihm arbeiten.

Pull Requests: Gitflow Workflow Pull Requests: Gitflow Workflow 2

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 master-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 Projekt-Maintainer 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.

Pull Requests: Forking workflow

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 master-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.

Pull Requests: Forking workflow

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 Master-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

Pull Requests: Fork the project

Um ihre Arbeit am Projekt beginnen zu können, muss Mary zunächst Johns Bitbucket-Repository abspalten. Hierzu meldet sie sich bei Bitbucket an, navigiert zu Johns Repository und klickt auf die Schaltfläche Fork.

Pull Request: Fork in Bitbucket

Nach der Eingabe des Namens und der Beschreibung des abgespaltenen Repositorys verfügt sie über eine serverseitige Kopie des Projekts.

Mary klont ihr Bitbucket-Repository

Pull Request: Clone the Bitbucket repo

Als Nächstes muss Mary das soeben abgespaltene 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.git

Beachte, dass mit git clone automatisch eine origin-Remote-Verbindung hergestellt wird, die zurück auf Marys abgespaltenes Repository verweist.

Mary entwickelt ein neues Feature

Pull Requests: develop a new 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 Projekt-Maintainer, den Überblick über den aktuellen Stand des Pull-Requests zu behalten.

Mary pusht das Feature in ihr Bitbucket-Repository

Pull Requests: Push feature to 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-branch

Nun kann der Projekt-Maintainer (oder bei Bedarf auch ein anderer Mitarbeiter) auf ihre Änderungen zugreifen.

Mary erstellt den Pull-Request

Pull Request: Create Pull Request

Nach der Übermittlung des Feature-Branch an Bitbucket kann Mary den Pull-Request über ihr Bitbucket-Konto erstellen. Dazu navigiert sie zu ihrem abgespaltenen 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 master 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.

Pull Request: Bitbucket

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

Pull Request: Bitbucket pull requests

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 Mergen klicken, um den Pull-Request zu genehmigen und Marys Feature in seinen master-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.

Pull Request: Comment

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 Master 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.

Möchtest du die Arbeit mit Pull-Request ausprobieren?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen