Mehr von Jürgen Gutsch

Mehr von Jürgen Gutsch

Empfehlungen von Jürgen Gutsch

Blog-Empfehlungen von Jürgen Gutsch

Willkommen bei ASP.NET Zone. Anmelden | Registrieren | Hilfe

Jürgen Gutsch

ASP.NET und mehr...
Working with Git – Part 4: Pull Requests

Inhalt der Serie

Warum?

In verteilten Teams, wie es z. B. bei Open Source Projekten üblich ist, aber auch in anderen Projekten mit externen Entwicklern, hat sich der Pull-Request als Review-Werkzeug durchgesetzt.

Im Grunde geht es darum, eine Anfrage zu erstellen, um seine Änderung am Code in den Hauptzweig übernehmen zu lassen. Das funktioniert in der Regel so, das man seinen Feature-Branch auf den Server pusht und die Verantwortlichen fragt, dass sie die Änderungen anschauen und ggf. übernehmen.

Im Gegensatz zu dem vorherigen Blog-Artikel zu den Feature-Branches, wird der Branch nicht gleich in den Hauptzweig zurückgeführt, sondern erst den Reviewern zur Verfügung gestellt. In den meisten Fällen eben, indem der Branch auf den Server gepusht wird.

Pull-Requests sind kein eigentliches Git Feature, sondern werden von Plattformen wie Github oder Bitbucket bereitgestellt. Auch einige weitere Git-Hosting-Plattformen unterstützen Pull-Request. Ob der TFS das ebenfalls unterstützt, kann ich zum jetzigen Zeitpunkt nicht sagen.

Die einfachste Art eines Pull-Requests (sollte man nicht über einen entsprechendes Git-Hosting verfügen) ist es, eine Email an das Team, oder dem entsprechenden Verantwortlichen Reviewer zu schreiben, mit der Bitte um ein Review des Codes im entsprechenden Feature-Branch. Der Reviewer, kann dann den Änderungen entweder zustimmen oder ablehnen. Im Falle dass er zustimmt, kann er die Änderungen dann gleich in den Hauptzweig übernehmen.

In Bitbucket (und auf Github) funktioniert das über eine Web-UI. Auf Bitbucket wird der zuletzt gepushte Feature-Branch beim erstellen eines Pul-Requests vorausgewählt. Man wählt dann den Ziel-Branch und beschreibt dann den Pull-Request mit einem Titel und einer optionalen Beschreibung. Abschließend werden die Reviewer zugeordnet. Der Review passiert ebenfalls in der Web-UI. Auf Bitbucket hilft die Möglichkeit Kommentare im Review für den Autor direkt an einer diskussionswürdigen Code-Stelle zu hinterlegen. Antworten auf die Kommentare lassen eine direkte Kommunikation zu.

Pull-Requests im Projekt-Alltag

Im Gegensatz zu Open-Source-Projekten, gibt es vielen Projekten kein Kernteam, das für das Review verantwortlich ist. Bei der YooApps z. B. ist das gesamte Projekt-Team verantwortlich. Was auch externe Entwickler mit einbezieht. Auch steht kein offizieller Reviewer zur Verfügung. Aus diesem Grund ist jeder im Team auch ein Reviewer. Der Autor des Pull-Requests fügt mehrere mögliche Reviewer hinzu. Der nächste der Zeit hat, schaut sich den Code an und nur einer muss dem Pull-Request zustimmen. Anders ist das kaum zu lösen, da die Pull-Requests zu lange liegen würden, während in der Zwischenzeit weitere Änderungen passieren. Immerhin wird der Code so von mindestens vier Augen angesehen. Fragen zum Code sollten nach Möglichkeit direkt besprochen werden, aber auch das ist nicht immer möglich, daher werden die Kommentarfunktionen eher genutzt.

Der Merge in den Hauptzweig wird dann allerdings wieder vom Autor übernommen und nicht vom Reviewer. Das ist deshalb so, weil wir – wie im Beitrag über die Feature-Branches beschrieben – die letzten Änderungen des Hauptzweiges vor dem Merge in den Feature-Branch übernehmen um Merge-Konflikte nicht im Hauptzweig lösen zu müssen. Der Reviewer müsste also sonst den Feature-Branch des Autors ggf. lokal auf seine Maschine holen. Nachdem dem Pull-Request also zugestimmt wurde, kommt der Autor wieder dran und führt seien Feature-Branch sauber wieder zurück in den Hauptzweig. Bitbucket bietet die Möglichkeit, den Pull Request auch direkt über die Web-UI zu mergen, allerdings wird dass dann schwieriger, wenn es zu Konflikten kommt. Daher sagen wir, dass der Autor auch für den Merge verantwortlich ist. Eine nützliche Funktion auf Bitbucket dagegen ist die Möglichkeit den reviewten Feature-Branch nach dem merge in den Entwickler-Zweig zu löschen. Dadurch bleibt die Branch-Liste auf dem Server klein.

Nochmal im Schnelldurchlauf

  1. Feature-Branch erstellen
  2. Implementieren
  3. Den aktuellen Stand des Entwickler-Branches holen und in den Feature-Branch mergen
    (Die Punkte 2. und 3. wiederholen sich ggf. mehrfach)
  4. Den Feature-Branch pushen
  5. Pull-Request erstellen
  6. Nach dem Review ggf. nachbessern
  7. Den aktuellen Stand des Entwickler-Branches holen und in den Feature-Branch mergen
  8. Den Feature-Branch in den Entwickler-Branch mergen
  9. Änderungen im Entwickler-Branch pushen
  10. Feature-Branch lokal ggf. löschen

Hier sieht man, dass vor jedem Push auf jeden Fall der aktuelle Stand des Entwickler-Branches in den Feature-Branch geholt wird. Das macht das Review einfacher und der Aufwand für den Merge verringert sich, da die Unterschiede zwischen dem Feature-Branch und dem Entwickler-Branch nicht so groß sind.

Fazit

Soviel zu der Art wie ich mit Git arbeite. Eigentlich recht einfach, oder? Wer weitere Hilfe oder Tipps benötigt, ist im Netz eigentlich bestens aufgehoben. Unmengen von Tipps und Tricks, Tutorials und Dokumentationen helfen einem beim schnellen Einstieg in das Thema Git. In meinem Fall halte ich es pragmatisch: Git hat eine umfangreiche API mit fielen Befehlen und Möglichleiten, allerdings mache ich mit nicht die Mühe alle zu kennen. Die wichtigsten zehn Kommandos schreibe ich blind, den Rest schaue ich nach. Schließlich muss man nicht alles Wissen, sondern nur wo die nötigen Informationen zu finden sind. ;)

BTW: Git lässt sich sehr gut üben und kann z. B. perfekt mit einer Code-Kata in einem Codeing-Dojo verknüpft werden. Definiert einfach jede Anforderung als Feature und setzt konsequent Feature-Branches um, vieleicht sogar Pull-Requests, wenn es die Infrastruktur zulässt ;)

BTW2: Wer Unterstützung benötigt, um in das Thema Git hinein zu kommen, kann mich sehr gerne kontaktieren. Einzelfragen antworte ich sehr gerne direkt. Intensivere Git-Schulungen können wir von der YooApps aus sehr gerne anbieten und natürlich bin ich auch immer gerne für eine Session bei einer Usergroup zu haben.

Posted: Dienstag, 12. Mai 2015 07:45 von Jürgen Gutsch
Anonyme Kommentare sind nicht zugelassen