Pull-Requests sind ein Feature, das Entwicklern, die Bitbucket nutzen, die Zusammenarbeit erleichtert. Sie bieten eine nutzerfreundliche Web-Oberfläche, um Code-Änderungen zu diskutieren, ehe sie ins offizielle Projekt integriert werden.
In seiner einfachsten Form ist der Pull-Request ein Mechanismus, mit dem ein Entwickler Teammitglieder über die Fertigstellung eines Features informieren kann. Sobald sein Feature-Branch soweit ist, setzt er über seinen Bitbucket-Account ein Pull-Request ab. So wissen alle Beteiligten, dass der Code reviewt und in den Master-Branch gemergt werden muss.
Doch ein Pull-Request ist mehr als nur eine Benachrichtigung – Er bietet ein dediziertes Forum, um das Feature zu diskutieren. Gibt es Probleme mit den Änderungen, können Teammitglieder im Pull-Request Feedback abgeben und das Feature sogar optimieren, indem sie Follow-up-Commits pushen. All diese Aktivitäten werden direkt im Pull-Request getrackt.
Verglichen mit anderen Kollaborations-Modellen ist diese formale Lösung zum Teilen von Commits ein sehr nahtloser Workflow. Sowohl SVN als auch Git können mit einem einfachen Skript automatisch Benachrichtigungs-E-Mails verschicken, doch wenn sie Änderungen diskutieren wollen, müssen die Entwickler sich an E-Mail-Theads halten. Das kann schnell planlos werden, gerade wenn Follow-up-Commits im Spiel sind. Pull-Requests bilden all diese Funktionalitäten mit einer nutzerfreundlichen Oberfläche im direkten Umfeld der Bitbucket-Repositories ab.
Anatomie eines Pull-Requests
Wenn ein Entwickler einen Pull-Request absetzt, fragt er an, dass ein anderes Teammitglied (oft der Projekt-Maintainer) einen Branch vom Repository des Entwicklers in sein eigenes Repository zieht. Das bedeutet, dass vier Informationen nötig sind, um einen Pull-Request abzusetzen: das Quell-Repository, der Quell-Branch, das Ziel-Repository und der Ziel-Branch.
Je nach Kollaborations-Worflow muss das Team verschiedene Werte gegebenenfalls spezifizieren. Das Diagramm oben zeigt einen Pull-Request, der anfragt, einen Feature-Branch in den offiziellen Master-Branch zu mergen, es gibt aber noch zahlreiche andere Möglichkeiten, Pull-Requests zu nutzen.
So funktioniert es
Pull-Requests können in Zusammengang mit dem Feature-Branch-Workflow, dem Gitflow-Workflow und dem Forking-Workflow zum Einsatz kommen. Da ein Pull-Request zwei eigenständige Branches und zwei eigenständige Repositories voraussetzt, greift das Konzept beim zentralisierten Workflow nicht. Je nach Workflow ist die Nutzung von Pull-Requests ziemlich unterschiedlich, aber der grundsätzliche Prozess ist der folgende:
- Der Entwickler arbeitet in einem dedizierten Branch in seinem lokalen Repository am Feature.
- Der Entwickler pusht den Branch in ein öffentliches Bitbucket-Repository.
- Der Entwickler setzt via Bitbucket ein Pull-Request ab.
- Der Rest des Teams reviewt den Code, diskutiert darüber und modifiziert ihn.
- 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 Kollaborations-Workflows funktionieren.
Der Feature-Branch-Workflow mit Pull-Requests
Der Feature-Branch-Workflow nutzt ein gemeinsames Bitbucket-Repository für die Zusammenarbeit und Features werden in isolierten Branches entwickelt. Doch statt die Änderungen unverzüglich in den Master-Branch zu mergen, setzen die Entwickler Pull-Requests ab, um Diskussionen rund um das Feature zu initiieren, ehe es in die Haupt-Codebasis integriert wird.
Dieser Workflow sieht nur ein einziges öffentliches Repository vor, weshalb das Ziel-Repository im Pull-Request dem Quell-Repository entspricht. In der Regel wird der Entwickler seinen Feature-Branch als Quell-Branch und den Master-Branch als Ziel-Branch spezifizieren.
Nach Erhalt des Pull-Requests muss der Projekt-Maintainer entscheiden, was zu tun ist. Wenn das Feature bereit zur Auslieferung ist, kann er es einfach in den Master-Branch mergen und den Pull-Request schließen. Wenn es mit den Änderungen jedoch Probleme gibt, kann er Feedback im Pull-Request posten. Folge-Commits erschienen direkt bei den relevanten Kommentaren.
Es ist auch möglich, einen Pull-Request für ein Feature abzusetzen, das unvollständig ist. Hat ein Entwickler beispielsweise Probleme mit der Implementierung einer bestimmten Anforderung, kann er einen Pull-Request erstellen, der den Zwischenstand seiner Arbeit enthält. Andere Entwickler können im Pull-Request Vorschläge anbieten oder das Problem direkt selbst mit zusätzlichen Commits lösen.
Der Gitflow-Workflow mit Pull-Request
Der Gitflow-Workflow ist dem Feature-Branch-Workflow ähnlich, definiert aber ein striktes Branching-Modell rund um das Projekt-Release. Die Ergänzung des Gitflow-Workflows um Pull-Requests bietet den Entwicklern einen bequemen Weg, um über Release- oder Maintenance-Branches zu sprechen, während sie an diesen arbeiten.
Die Mechanismen von Pull-Requests sind im Gitflow-Workflow exakt dieselben wie die im Abschnitt davor beschriebenen: Ein Entwickler setzt einfach einen Pull-Request ab, wenn ein Feature, ein Release oder ein Hotfix reviewt werden muss, und der Rest des Teams erhält via Bitbucket Benachrichtigungen.
Features werden normalerweise in den Develop-Branch gemergt, während Release- und Hotfix-Branches sowohl in den Develop- als auch den Master-Branch gemergt werden. Pull Requests können genutzt werden, um all diese Merges effizient zu managen.
Der Forking-Workflow mit Pull-Requests
Im Forking-Workflow pusht ein Entwickler sein fertiggestelltes Feature in sein eigenes öffentliches Repository statt in ein gemeinsames. Anschließend setzt er einen Pull-Request ab und lässt den Projekt-Maintainer so wissen, dass es reviewt werden kann.
In diesem Workflow sind die Benachrichtigungen zu Pull-Request besonders nützlich, denn der Projekt-Maintainer hat sonst keine Möglichkeit, automatisch davon zu erfahren, wenn ein anderer Entwickler Commits zu seinem Bitbucket-Repository hinzugefügt hat.
Da jeder Entwickler sein eigenes öffentliches Repository hat, sind Quell- und Ziel-Repository in einem Pull-Request verschieden. Das Quell-Repository ist das öffentliche Repository des Entwicklers, der Quell-Branch ist derjenige, der die Änderungen enthält. Wenn der Entwickler versucht, das Feature in die Haupt-Codebasis zu mergen, ist das Ziel-Repository das offizielle Projekt und der Ziel-Branch der Master-Branch.
Pull-Requests eigenen sich auch dazu, mit Entwicklern außerhalb des offiziellen Projekts zusammenzuarbeiten. Wenn zum Beispiel ein Entwickler mit einem Teammitglied an einem Feature gearbeitet hat, könnte er einen Pull-Request absetzen, der das Bitbucket des anderen als Ziel ausweist statt das offizielle Projekt. Quell-Branch und Ziel-Branch entsprechen demselben Feature-Branch.
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 sehr mächtigen Kollaborations-Werkzeug im Rahmen des Forking-Workflows. Der Folgeartikel bietet ein konkretes Beispiel für die Zusammenarbeit mithilfe von Pull-Requests.
Weiterführende Infos: Ihr Partner für Git und Stash
Kennen Sie Stash von Atlassian? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.
Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.
Git und Stash in der Software-Entwicklung: Eine Einführung
Stash in der Praxis
Stash Enterprise: Git-Repository-Management in großen Unternehmen
So funktioniert die Lizenzierung von Atlassian-Produkten
