Amazon Web Services für Entwickler, Teil 4

Pull-Requests, Commits und Branches in AWS CodeCommit

| Autor / Redakteur: Thomas Drilling / Stephan Augsten

Für die Pull-Anfrage ist es notwendig, einen Code-Branch zu erstellen.
Für die Pull-Anfrage ist es notwendig, einen Code-Branch zu erstellen. (Bild: Drilling / AWS)

Nutzer der Amazon Web Services möchten ihre Code-Repositories möglicherweise zentral in AWS CodeCommit hosten. Wie man mit dem Git-ähnlichen Service arbeitet, sehen wir uns in diesem Beitrag genauer an.

AWS CodeCommit ist ein vollständig verwalteter Service zur Quellcode-Kontrolle. Nachdem Nutzer ein neues Repository auf AWS CodeCommit angelegt und mit ihrem lokalen Git-Client abgeglichen oder von diesem importiert haben, können auch andere Team-Mitglieder mit dem gehosteten Quellcode-Service arbeiten. Ein typischer Workflow in AWS CodeCommit könnte dabei etwa wie folgt aussehen.

Angenommen, ein Entwickler nutzt ein bestimmtes Repository (im Beispiel „drilling-nodejs“) und möchte eine neue Funktion für die künftige Version der Software verbessern. Dazu muss er zunächst seine Arbeit vom aktuellen produktionsbereiten Teil des Codes trennen und erstellt dazu einen so genannten „Branch“, der vom Standard-Branch „abzweigt“. Dieser bekommt einen aussagekräftigen Namen, wie z. B. „march-release_new_feature-survey“.

Im Zuge der Arbeit an der neuen Funktion implementiert der Entwickler dann z. B. neuen Code, führt Commits durch und überträgt den neuen Funktionscode auf den zu diesem Zweck abgezweigten Branch. Möchte er dann seine Code-Qualität durch andere Repository-Benutzer prüfen lassen, bevor er seine Änderungen in den Standard-Branch einfügt, muss er eine so genannte Pull-Anforderung stellen.

Diese Pull-Anforderung besteht aus einem Vergleich (Compare) zwischen dem Branch mit seinen Neuerungen und dem Branch mit dem Code, mit dem die Änderungen zusammengeführt werden sollen, also hier der Standard-Branch. Es sind aber durchaus auch mehrere Ebenen vorstellbar. Jetzt können andere Benutzer den neuen Code des Benutzers prüfen, indem sie z. B. Änderungen, Kommentare oder Vorschläge hinzufügen.

Der Entwickler kann den Branch dann in Reaktion auf die eingegangenen Kommentare, ggf. auch mehrfach mit Code-Änderungen aktualisieren. Überträgt er seine Änderungen mittels Push in den Branch auf AWS CodeCommit, werden seine Änderungen in die Pull-Anforderung einbezogen. Er kann auch Änderungen einbeziehen, die im vorgesehenen Ziel-Branch vorgenommen wurden, obwohl die Pull-Anforderung noch offen ist.

Somit können alle Benutzer sicher sein, dass sie alle Änderungsvorschläge im Kontext wahrnehmen. Ist der Entwickler schließlich ebenso zufrieden, wie seine „Prüfer“, führt er seinen Code mit dem bestehenden Code zusammen und schließt die Pull-Anforderung.

Repository durchforsten

Bevor man den ersten Pull-Request erstellt, sobald man sich damit vertraut machen, wie man die Inhalte eines vorhandenen Repository durchsucht. Hierzu wählt der Nutzer in der AWS CodeCommit-Konsole zunächst das gewünschte Repo aus der Repository-Liste aus.

Die Branch-Ansicht mit dem Default-Zweig „Master“.
Die Branch-Ansicht mit dem Default-Zweig „Master“. (Bild: Drilling / AWS)

Per Default wird der Inhalt des Repository im Standardzweig angezeigt. Im Menü „Branches“ lassen sich mit „Create Branch“ eigene Branches erstellen und später in der Ansicht zwischen den Unterzweigen wechseln. Der Branch mit dem Namen „Master“ ist immer vorhanden und standardmäßig der sogenannte Default-Branch.

In der „Code“-Ansicht wird aber in jedem Fall der Standard-Branch des gewählten Repository angezeigt. Zum Anzeigen eines anderen Zweigs genügt ein Klick auf in das Feld der Ansichtsauswahl. Die weitere Navigation ist weitgehend intuitiv und selbsterklärend. Möchte der Nutzer den Inhalt eines Verzeichnisses anzeigen, wählt er es in der Navigationsliste aus.

Blick in den Inhalt einer Datei.
Blick in den Inhalt einer Datei. (Bild: Drilling / AWS)

Um den Inhalt einer Datei anzuzeigen, wählt man diese ebenfalls einfach in der Liste aus. Allerdings lässt sich die Datei nicht in der Konsole anzeigen, wenn deren Größe den Grenzwert des Commit-Objekts überschreitet. In diesem Fall muss die Datei in einem lokalen Repository aufgerufen werden. Für das Schließen der Dateiansicht genügt es, in der „Code“-Navigationsleiste wieder das gewünschte anzuzeigende Verzeichnis auszuwählen.

Beim Anzeigen einer Binärdatei erfolgt eine Warnmeldung, die der Nutzer vor der Anzeige zu bestätigen hat. Wählt der Nutzer hingegen eine Markdown-Datei (.md) aus, kann er mit den Schaltflächen für „Rendered Markdown“ und „Markdown Source“ zwischen der gerenderten Ansicht und der Syntaxansicht wechseln.

Einen Branch erstellen

Um nun eine erste Pull-Anfrage erstellen zu können, muss der jeweilige Nutzer zunächst im Menü „Branches“ einen neuen Code-Zweig erstellen, der dann die zu überprüfenden neuen Code-Änderungen enthält:

Für die Pull-Anfrage ist es notwendig, einen Code-Branch zu erstellen.
Für die Pull-Anfrage ist es notwendig, einen Code-Branch zu erstellen. (Bild: Drilling / AWS)

Im Listen-Feld „Branch from“ ist der Master vorausgewählt. Selbstverständlich ist es auch möglich, den neuen Branch auf Basis eines anderen Unterzweigs oder sogar eines ganz bestimmten Commits zu erstellen. Auch wenn die CodeCommit-Konsole den schnelleren Weg darstellt, werden die meisten Entwickler einen neuen Branch wohl eher im lokalen Repository erstellen und erst dann auf das AWS CodeCommit-Repo übertragen. Das setzt allerdings voraus, dass die Verbindung vom lokalen Repository zu CodeCommit bereits eingerichtet ist, wie im letzten Teil gezeigt.

Ist das der Fall, lässt sich der neuen Zweig wie folgt auch mit git erstellen.

git checkout -b <neuer Branch>

Das Übertragen des neuen Branches vom lokalen Repository nach AWS CodeCommit erfolgt dann mit dem Kommando „git push“, welches als Parameter „remote-name“ bzw. „origin“ sowie „new-branch-name“ erwartet, also nach folgendem Muster:

git push <origin> <neuer Branch>

Einen Pull-Request erstellen

Schauen wir uns jetzt an, was man im Kontext von Git und AWS CodeCommit unter einer Pull-Anforderung genau versteht. Per Pull-Anforderung kann jedes mit passenden Git-Credentials ausgestattete Mitglied des Entwicklungsteams die Code-Änderungen anderer Nutzer prüfen, kommentieren und über Branches hinweg zusammenführen. Dies umfasst sowohl kleine Änderungen und Fehlerkorrekturen als auch größere Funktionserweiterungen oder neu veröffentlichte Versionen.

Über eine Pull-Anforderung lassen sich Code-Änderungen prüfen und zusammenführen.
Über eine Pull-Anforderung lassen sich Code-Änderungen prüfen und zusammenführen. (Bild: Drilling / AWS)

Dazu wechselt man jetzt – unter der Annahme, dass die geplanten Code-Änderungen inzwischen erfolgt sind – ins Menü „Branches“. Hier klickt man auf denjenigen Branch, der die zu prüfenden Änderungen enthält, wodurch ein erneuter Wechsel zur Code-Ansicht erfolgt.

Nun kann der Nutzer auf „Create pull request“ klicken, wodurch die Ansicht ins Menü „Pull requests“ wechselt. Hier wählt der Nutzer dann im Listen-Menü „Source…“ den Branch aus, der die zu prüfenden Änderungen enthält. Da wir exakt von diesem Zweig gekommen sind, sollte hier bereits der passende Branch eingetragen sein.

Im Menü „Destination: … “ ist als Ziel ebenfalls korrekt der Standard-Branch des Repositorys vorkonfiguriert. Trotzdem könnte man an dieser Stelle optional auch ein anderes Ziel wählen, etwa wenn der Nutzer den Code nach Abschluss der Pull-Anforderung mit einem anderen Branch zusammenführen und diesen dann mittels Klick auf „Compare“ mit der Quelle vergleichen möchte.

Mit wenigen Klicks lassen sich Quell- und Ziel-Branches zusammenführen.
Mit wenigen Klicks lassen sich Quell- und Ziel-Branches zusammenführen. (Bild: Drilling / AWS)

Dem blauen Hinweis in der Abbildung lässt sich entnehmen, dass in diesem Fall der Code in Destination und Source identisch ist, was in diesem „Fake“-Beispiel korrekt ist. Trotzdem vergeben wir jetzt einen Titel und eine Beschreibung für den Pull request und klicken auf „Create“, wodurch die Liste der für dieses Repository gültigen Pull-Anforderungen erweitert wird. Die Ansicht lässt sich jederzeit nach offenen Anfragen, geschlossene Anfragen oder von selbst erstellten Anfragen filtern.

Hat man die in Teil 3 beschrieben Benachrichtigungen für das Repository konfiguriert, damit andere Nutzer über die Pull-request-Ereignisse benachrichtigt werden, erhalten diese jetzt eine neue E-Mail zur Anfrage. Andere Nutzer können jegliche Änderungen für bestimmte Dateien, Code-Zeilen oder Pull-Requests allerdings selbst sehen und auch jederzeit auf Kommentare antworten. Man kann aber auch Änderungen an den Pull-Request-Branch senden, der dann die Anfrage aktualisiert.

Ist der Ersteller irgendwann der Ansicht, dass sämtliche Code-Änderungen zufriedenstellend überprüft wurden und alle anderen Nutzer mit den Änderungen einverstanden sind, hat er zwei Möglichkeiten:

Er kann aus der Pull-Anfrage heraus „Merge“ verwenden. So führt er die Branches beim Schließen der Anfrage automatisch mit der Fast-Forward-Merge-Option zusammen.

Alternativ kann er auch „Close pull-request“ wählen. So schließt er die Pull-Anfrage, ohne die Branches automatisch zusammenzuführen, etwa wenn es Konflikte gibt, die nicht automatisch aufgelöst werden können.

Arbeiten mit Commits

Unter einen Repository-Commit versteht man einen Snapshot der Inhalte und der an den Inhalten des Repositorys vorgenommen Änderungen. Führt ein Benutzer einen Commit aus und stößt damit eine Änderung an, speichert AWS CodeCommit diese Informationen, ebenso „wer“ die Änderung ausgeführt hat und das Datum sowie die Uhrzeit des Commits. Ebenfalls gespeichert werden die mit dem Commit ausgeführt Änderungen. Dabei kann man zur einfacheren Identifizierung spezifische Commit-Tags verwenden.

Das Commit-Menü bietet mehrere Möglichkeiten. Man kann z. B. Commits überprüfen, den Commit-Verlauf in einem Diagramm darstellen, einen Commit mit dem übergeordneten Commit vergleichen und dem eigenen Commits Kommentare hinzufügen oder auf Kommentare anderer Benutzer antworten.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45268804 / Quellcode-Management)