Git-Workflows: Der Pull-Request-Workflow (Teil 2)

Im letzten Beitrag wurde das Konzept der Pull-Requests im Rahmen der Git-Entwicklung grundsätzlich vorgestellt. Das folgende Beispiel demonstriert, wie Pull-Requests im Rahmen des Forking-Workflows zum Einsatz kommen 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 Entwickler A eben ein Programmierer und Entwickler B der Projekt-Maintainer. Beide haben ihre eigenen öffentlichen Bitbucket-Repositories, die von Entwickler B enthält das offizielle Projekt.

Entwickler A forkt das offizielle Projekt

Git Pull-Requests 7

Um die Arbeit am Projekt zu beginnen, muss Entwickler A zunächst das Bitbucket-Repository von Entwickler B forken. Das geschieht, indem er sich in Bitbucket einloggt, zum Repository von B navigiert und den Fork-Button drückt.

Git Pull-Requests 8

Nachdem er Name und Beschreibung der geforkten Repository eingegeben hat, hat er eine serverseitige Kopie des Projekts.

A klont sein Bitbucket-Repository

Git Pull-Requests 10a

Dann muss A das Bitbucket-Repository klonen, das er soeben geforkt hat. Damit hat er eine funktionierende Kopie des Projekts auf seiner lokalen Maschine. Dazu führt er das folgende Kommando aus:

git clone https://user@bitbucket.org/user/repo.git

Wie schon beschrieben: git clone erzeugt automatisch eine origin-Remote-Verbindung, die zurück auf das geforkte Repository von A zeigt.

A entwickelt ein neues Feature

Git Pull-Requests 12

Bevor er irgendwelchen Code schreiben kann, muss A einen neuen Branch für das Feature erzeugen. Diesen nutzt er später als Quell-Branch für den Pull-Request.

git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"

A kann so viele Commits machen, wie er für das Feature benötigt. Und wenn die Feature-Historie unordentlicher als gewünscht ist, kann er ein interaktives Rebase nutzen, um unnötige Commits zu entfernen. In größeren Projekten macht das Aufräumen der Feature-Historie es dem Projekt-Maintainer viel einfacher zu überblicken, was in einem Pull-Request vor sich geht.

A pusht das Feature in sein Bitbucket-Repository

Git Pull-Requests 10

Wenn das Feature fertiggestellt ist, pusht A den Feature-Branch in sein eigenes Bitbucket-Repository (nicht in das offizielle):

git push origin some-branch

Damit werden seine Änderungen für den Projekt-Maintainer verfügbar (oder für jeden Beteiligten, der darauf Zugriff haben muss).

A erstellt den Pull-Request

Git Pull-Requests 13

Nun, da Bitbucket seinen Feature-Branch hat, kann Entwickler A über seinen Bitbucket-Account die Pull-Request erstellen, indem er zu seinem geforkten Repo navigiert und den entsprechenden Button klickt. Das folgende Formular setzt das Repository von A als Quell-Repository und fragt nach der Spezifizierung des Quell-Branchs, des Ziel-Repositorys und des Ziel-Branchs.

A möchte sein Feature in die Haupt-Codebasis mergen. Somit ist der Quell-Branch sein Feature-Branch, das Ziel-Repository das öffentliche Repo von Entwickler B und der Ziel-Branch der Master-Branch. Der Pull-Request muss außerdem einen Titel und eine Beschreibung erhalten. Wenn noch andere Personen außer B den Code verfizieren sollen, kann A sie im Reviewer-Feld hinzufügen.

Bitbucket Screenshot 1

Nach dem Erstellen des Pull-Requests erhält B eine Benachrichtigung in seinem Bitbucket-Feed und (optional) per E-Mail.

B reviewt den Pull-Request

Bitbucket Screenshot 2

Entwickler B, der Projekt-Maintainer, kann in seinem eigenen Bitbucket-Repository auf alle so erstellten Pull-Requests zugreifen. Ein Klick auf den Pull-Request von A zeigt ihm eine Beschreibung, die Feature-Commit-History und alle enthaltenen Änderungen in der Diff-Ansicht.

Ist er der Meinung, dass das Feature bereit für die Auslieferung ist, muss er nur der Merge-Button drücken, um den Pull-Request zu bestätigen und das Feature in seinen Master-Branch zu mergen.

Doch in diesem Beispiel entdeckt B im Code von A einen kleinen Bug, den dieser vor dem Mergen fixen muss. B kann den Pull-Request als Ganzes kommentieren oder einem spezifischen Commit in der Feature-History einen Kommentar hinzufügen.

Bitbucket Screenshot 3

A ergänzt einen Follow-up-Commit

Wenn Entwickler A irgendwelche Fragen zu diesem Feedback hat, kann er innerhalb des Pull-Requests reagieren und quasi ein Diskussionsforum zu seinem Feature etablieren.

Um den Fehler zu korrigieren, fügt A seinem Feature-Branch einen weiteren Commit hinzu und pusht ihn in sein Bitbucket-Repository, ganz wie beim ersten Mal. Dieser Commit wird im originalen Pull-Request automatisch hinzugefügt und B kann die Änderungen erneut reviewen, und zwar direkt neben seinem initialen Kommentar.

B akzeptiert den Pull-Request

Schließlich akzeptiert B die Änderungen, mergt den Feature-Branch in den Master-Branch und schließt den Pull-Request. Das Feature ist nun in das Projekt integriert und andere Entwickler, die an diesem mitarbeiten, können es mit dem bekannten Kommando git pull in ihre eigenen lokalen Repositories ziehen.

Fazit

Dies sind die Werkzeuge, um Pull-Requests in einen bestehenden Workflow zu integrieren. Pull-Requests sollen die vorgestellten Workflows für die Zusammenarbeit auf Basis von Git keineswegs ersetzen, vielmehr bieten sie eine komfortable Ergänzung zu diesen Prozessen, um die Kollaboration allen Teammitgliedern besser zugänglich zu machen.

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

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar