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