Das Besondere an GitHub ist, dass es nicht nur eine einfache Möglichkeit bietet, eigene Git-Repositorys zu hosten, sondern auch, dass andere Personen oder Organisationen mit wenigen Schritten Änderungen an Repositorys vorschlagen können. Die Maintainer des Projekts können dann die Änderungen reviewen, kommentieren, akzeptieren oder auch ablehnen. Der GitHub Workflow dient als Übersicht über die Arbeitsweise von und mit GitHub: vom Forken über das Erstellen von Pull-Requests bis zum Code-Review. Einige Teile, die im Folgenden behandelt werden, sind für alle Entwicklungsprozesse relevant. Einige sind wiederum sehr spezifisch für das Beitragen zu Open-Source-Projekten.
Forken
Im GitHub-Kontext finden häufig die Wörter »Forken« und »Pull-Request« Verwendung. Im Default-Zustand besitzt nur der Repository-Inhaber Schreibrechte an einem Repository, dies ist entweder eine einzelne Person oder eine Organisation. Um nun die Änderungen an einem fremden Repository vorzuschlagen, muss das Ziel-Repository geforkt werden. Bei einem Fork handelt es sich um eine Abspaltung. Hin und wieder liest man bei bekannteren Open-Source-Projekten, dass aus verschiedenen Gründen ein Fork entstanden ist. So ist die Office-Suite LibreOffice ein Fork von Apache OpenOffice, in das allerdings nicht die Änderungen an Apache OpenOffice zurückgeflossen sind.
Wenn bei GitHub von einem Fork die Rede ist, dann heißt es in der Regel, dass geforkt wird, um Änderungen zum Ursprungsprojekt beitragen zu können. Das Forken kann direkt über die Webseite von GitHub erfolgen. Letztendlich wird eine Kopie des Repositorys, das ist dann der Fork, im eigenen Account abgelegt. Dort sind dann im Gegensatz zum fremden Repository vollständige Zugriffsrechte vorhanden. Dies ist eine sehr einfache und bequeme Möglichkeit, um ein Repository zu klonen.
Alternativ ist es weiterhin möglich, das Repository lokal zu klonen, sich in GitHub ein neues Repository zu erstellen und anschließend das lokale Repository wieder hochzuladen. Ein weiterer Vorteil bei der Fork-Funktion auf GitHub ist, dass der Fork mit dem ursprünglichen Repository verknüpft ist. Wenn ihr also an dem Repository svijee/git-buch-website Änderungen vorschlagen wollt, dann müsst ihr es auf GitHub forken, sodass es anschließend unter $GH_USER/gitbuch-website verfügbar ist.
Nach dem Klick auf den FORK-Button dauert das Erstellen des Forks ein paar Sekunden. Der Fork ist anschließend mit dem Ursprungs-Repository verlinkt, sodass Außenstehende direkt sehen, dass es kein vollständig eigenes, sondern ein geforktes Repository ist.
Pull-Request erzeugen
Da an dem Fork vollständige Schreibrechte vorhanden sind, könnt ihr dort alles tun, was ihr möchtet. Ziel des Ganzen ist allerdings in der Regel, Änderungen zu machen, die dem Maintainer des Repositorys gefallen, damit sie in das Hauptprojekt mit einfließen können. Zunächst müsst ihr also das geforkte Repository lokal klonen.
$ git clone git@github.com:$GH_USER/git-buch-webseite.git
$ cd git-buch-webseite
$GH_USER sollte natürlich durch den eigenen GitHub-Namen ersetzt werden. Git-Hub rät, jedem Repository eine LICENSE- und README-Datei hinzuzufügen. Da diese noch fehlen, können sie ganz einfach im lokalen Repository hinzugefügt werden. Zuvor soll in diesem Beispiel allerdings ein neuer Branch angelegt werden.
$ git checkout -b add-readme
Wie ihr den Branch nun benennt, kann eine Geschmacksfrage sein. Ein häufiger und gängiger Ansatz ist, dass aus dem Branchnamen prinzipiell hervorgehen sollte, was in dem Branch erledigt wurde. Da eine README.md-Datei hinzugefügt wird, kann der Branch auch ganz einfach add-readme heißen. Die hinzuzufügende README.md-Datei beinhaltet in der Regel eine einfache Beschreibung des Projekts und gegebenenfalls, wie und wo Fehler zu melden sind. Nach dem Erstellen der Datei könnt ihr wie gewohnt ein Commit erstellen.
$ git add README.md
$ git commit -m ″Füge README.md Datei hinzu“
Zur Wiederholung: Wichtig ist an diesem Punkt, nicht zu vergessen, den Branch des Repositorys zu pushen, ansonsten sind diese Änderungen nur lokal und nicht auf GitHub vorhanden.
$ git push origin add-readme
Nach dem Pushen könnt ihr über GitHub den sogenannten Pull-Request erstellen. Darin können die Änderungen an dem Haupt-Repository zur Übernahme vorgeschlagen werden. Bei jedem Repository, in dem die Pull-Request-Funktion nicht abgeschaltet wurde, findet sich auf seiner Startseite ein grüner Button mit COMPARE & PULL REQUEST, über den der Pull-Request angelegt werden kann. Im Menü des Repositorys findet sich ebenfalls eine Übersicht über alle offenen Pull-Requests, wo man im Vorhinein nachschauen kann, ob nicht jemand schon den gleichen Änderungsvorschlag gemacht hat.
Beim Anlegen eines Pull-Requests müsst ihr beide Branches und beide Repositorys angeben, das wäre dann der Branch aus dem Fork, der in den Entwicklungsbranch des Haupt-Repositorys gemergt werden soll. In diesem Beispiel ist das add-readme nach master. Der Pull-Request muss allerdings von dem eigenen Fork aus erstellt werden. Bevor ihr den Pull-Request anlegt, habt ihr die Möglichkeit, ein Diff beider Branches im Browser anzuschauen, um anschließend den Pull-Request zu stellen. Zusätzlich müsst ihr einen Titel setzen. Optional ist auch eine Beschreibung möglich. Hierbei ist zu beachten, dass sowohl Titel als auch Beschreibung klar und ausführlich sein sollten. Die Maintainer, die den Pull-Request überprüfen, müssen schließlich sehen und erkennen, welchen Mehrwert das Projekt durch die Annahme erfährt. Ein eindeutiger Titel, eine hilfreiche Beschreibung und übersichtliche Commits helfen dabei sehr. Häufig wird hier auch noch eine Referenz zu einem existierenden Ticket gezogen.
Bevor ihr bei fremden Repositorys Pull-Requests anlegt, solltet ihr prüfen, ob und in welcher Form Änderungen zugeführt werden sollen. Vor allem bei größeren Änderungen bietet es sich an, den Maintainer zu kontaktieren, bevor zu viel Zeit in einen Pull-Request gesteckt wird, wenn die Änderungen letztendlich doch nicht gebraucht werden oder nicht den Anforderungen der Maintainer entsprechen. Auch ein Blick in die bestehenden Issues des Projekts ist häufig sehr hilfreich.
Wenn ihr nun einen Pull-Request anlegt, werden unterhalb der Beschreibung die Commits inklusive ihrer Commit-Message angezeigt. Darunter seht ihr dann den Diff, den ihr euch definitiv anschauen solltet. Das ist insbesondere deshalb wichtig, damit die richtigen Änderungen in dem Pull-Request landen.
Pull Request überprüfen
Die Maintainer können anschließend ein Review des Pull-Requests durchführen. Die Reviewer können in dem Pull-Request Kommentare abgeben, sei es an einzelnen Zeilen oder als generellen Kommentar. Sofern ihr alle Hinweise berücksichtigt habt, kann der Pull-Request von dem Projekt-Maintainer angenommen werden und eure Änderungen sind somit erfolgreich in das Projekt geflossen.
Dieser Artikel ist ein Auszug aus dem Buch „Versionsverwaltung mit Git“ von Sujeevan Vijayakumaran. Alle Infos zum Buch, das Inhaltsverzeichnis und eine kostenlose Leseprobe findet ihr bei uns im Shop.