6.3 GitHub - Ein Projekt betreuen

Jemand meldet sich bei Ihnen, bearbeitet Ihren Code und sendet Ihnen einen Pull-Request. In diesem Fall sollten Sie eine E-Mail erhalten, in der Sie über den neuen Pull-Request informiert werden und dieser sollte etwa so aussehen wie in E-Mail Benachrichtigung über einen neuen Pull-Request.

Es gibt ein paar Punkte, die man bei dieser E-Mail beachten sollte. Es gibt ein kleines diffstat – eine Liste von Dateien, die sich im Pull Request geändert haben und um wieviel. Sie erhalten einen Link zum Pull Request auf GitHub. Sie enthält auch ein paar URLs, die Sie von der Kommandozeile aus verwenden können.

Wenn Sie die Zeile sehen, die git pull <url> patch-1 lautet, ist das eine einfache Möglichkeit, aus einer entfernten Branch zu mergen, ohne einen Remote hinzufügen zu müssen. Wir haben das in Kapitel 5, Remote-Branches auschecken kurz besprochen. Wenn Sie möchten, können Sie einen Themen-Branch erstellen und in diesen wechseln (engl. checkout) und dann diesen Befehl ausführen, um die Änderungen in dem Pull-Request zu mergen.

Die anderen interessanten URLs sind die .diff und .patch URLs, die, wie Sie vielleicht vermuten, vereinheitlichte Diff- und Patch-Versionen des Pull Requests bereitstellen. Technisch gesehen könnten Sie die Arbeit im Pull-Request mit einem Befehl wie diesem zusammenführen:

Wie in Github Workflow beschrieben, können Sie nun eine Diskussion mit der Person führen, die den Pull Request geöffnet hat. Sie können bestimmte Code-Zeilen kommentieren, ganze Commits kommentieren oder den gesamten Pull-Request selbst kommentieren, indem Sie „GitHub Flavored Markdown“ an beliebiger Stelle verwenden.

Jedes Mal, wenn jemand den Pull-Request kommentiert, erhalten Sie weitere E-Mail-Benachrichtigungen, damit Sie wissen, dass Aktivitäten stattfinden. Sie werden jeweils einen Link zum Pull Request enthalten, in dem die Aktivität stattfindet. Auf die E-Mails können Sie auch direkt antworten, um den Pull-Request-Thread zu kommentieren.

Sobald der Quellcode richtig platziert ist und Sie ihn zusammenführen möchten, können Sie ihn mit der Anweisung git pull <url> <branch> (wie zuvor gesehen) pullen und lokal mergen oder Sie fügen den Fork als Remote hinzu, fetchen den Patch und mergen ihn anschließend.

Wenn das Zusammenführen trivial ist, können Sie auch einfach auf der GitHub-Seite auf die Schaltfläche „Merge“ klicken. Dadurch wird ein „non-fast-forward“ Merge durchgeführt, wodurch ein Merge-Commit erstellt wird, auch wenn ein „fast-forward“ Merge möglich gewesen wäre. Das bedeutet, dass unabhängig davon, was Sie tun, jedes Mal, wenn Sie auf die Schaltfläche Merge klicken, ein Merge-Commit erstellt wird. Wie Sie in Merge-Button und Anweisungen zum manuellen Zusammenführen eines Pull-Requests sehen können, gibt Ihnen GitHub all diese Informationen, wenn Sie auf den Hinweis-Link klicken.

Wenn Sie sich entscheiden, dass Sie ihn nicht zusammenführen möchten, können Sie auch einfach den Pull-Request schließen und die Person, die ihn geöffnet hat, wird benachrichtigt.

Wenn Sie mit vielen Pull-Requests zu kämpfen haben und nicht jedes Mal einen ganzen Batzen Remotes hinzufügen oder einmalige Pulls durchführen wollen, gibt es einen tollen Kniff, den GitHub Ihnen anbietet. Es handelt sich um einen fortgeschrittenen Kunstgriff, den wir in Kapitel 10, Refspecs ausführlicher durchgehen werden. Er kann jedoch recht nützlich sein.

GitHub preist die Pull-Request-Branches für ein Repository als eine Art Pseudo-Zweig auf dem Server an. Normalerweise werden sie beim Klonen nicht angezeigt, aber sie sind verdeckt vorhanden und man kann ziemlich leicht darauf zugreifen.

Um das zu verdeutlichen, werden wir den Low-Level-Befehl ls-remote verwenden, der oft als „plumbing“ Befehl bezeichnet wird und über den wir in Basisbefehle und Standardbefehle (Plumbing and Porcelain) mehr lesen werden. Dieses Kommando wird im Regelfall nicht im täglichen Gebrauch von Git verwendet, aber es ist zweckmäßig, um uns zu zeigen, welche Referenzen auf dem Server vorhanden sind.

Wenn wir diesen Befehl gegen das „blink“ Repository ausführen, das wir vorhin benutzt haben, erhalten wir eine Liste aller Branches und Tags, sowie anderer Referenzen im Repository.

Wenn Sie sich in Ihrem Repository befinden und git ls-remote origin ausführen (oder auch einen beliebigen anderen Remote, den Sie überprüfen möchten), dann wird Ihnen das etwas Vergleichbares angezeigt.

Wenn sich das Repository auf GitHub befindet und Sie irgendwelche geöffnete Pull-Requests haben, werden diese Referenzen mit vorangestelltem refs/pull/ angezeigt. Das sind im Prinzip Branches, die aber nicht unter refs/heads/ stehen. Sie werden normalerweise nicht angezeigt, wenn Sie klonen oder vom Server fetchen – der Fetching-Prozess ignoriert sie normalerweise.

Es gibt zwei Referenzen pro Pull-Request – eine endet mit /head. Sie zeigt auf genau den gleichen Commit wie der letzte Commit in der Pull-Request-Branch. Wenn also jemand einen Pull-Request in unserem Repository öffnet und sein Branch bug-fix heißt, der auf a5a775 zeigt, dann haben wir in unserem Repository keinen bug-fix Zweig (weil der in seinem Fork liegt). Aber wir werden pull/<pr#>/head bekommen, der auf a5a775 zeigt. Das heißt, wir können ziemlich einfach jeden Pull-Request-Branch in einem Rutsch herunterladen, ohne einen Stapel Remotes hinzufügen zu müssen.

Jetzt könnten Sie das Fetchen der Referenz direkt durchführen.

Git erhält die Meldung: „Verbinden Sie sich mit dem origin Remote und laden Sie die Referenz refs/pull/958/head herunter.“ Git folgt gern und lädt alles herunter, was Sie brauchen, um diesen Ref zu erstellen. Es setzt einen Zeiger auf den Commit, den Sie unter .git/FETCH_HEAD haben wollen. Sie können das mit git merge FETCH_HEAD in einen Branch fortsetzen. In diesem wollen Sie testen, aber die Merge-Commit-Nachricht sieht ein wenig merkwürdig aus. Wenn Sie viele Pull-Requests überprüfen müssen, wird das umständlich.

Es gibt auch eine Möglichkeit wie Sie alle Pull-Requests abrufen und aktuell halten können, wann immer Sie sich mit dem Remote verbinden. Öffnen Sie .git/config in Ihrem bevorzugten Editor und suchen Sie nach dem origin Remote. Es sollte ein bißchen wie folgt aussehen:

Die Zeile, die mit fetch = beginnt, ist eine „refspec.“ Es ist eine Möglichkeit, Namen auf dem Remote den Namen in Ihrem lokalen .git Verzeichnis zuzuordnen. Das sagt Git speziell: „die Sachen auf dem Remote, die unter refs/heads liegen, sollten in meinem lokalen Repository unter refs/remotes/origin abgelegt werden.“ Sie können diesen Teil ändern, um eine weitere Referenz (refspec) hinzuzufügen:

Diese letzte Zeile meldet Git: „Alle Referenzen, die wie refs/pull/123/head aussehen, sollten lokal als refs/remotes/origin/pr/123 gespeichert werden.“ Wenn Sie jetzt diese Datei speichern und ein git fetch ausführen, passiert folgendes:

Nun werden alle Remote-Pull-Requests lokal mit Referenzen (refs) abgebildet, die sich ähnlich wie das Tracken von Branches verhalten; sie sind schreibgeschützt und werden aktualisiert, wenn Sie einen Fetch durchführen. Dadurch ist es besonders einfach, den Code aus einer Pull-Anforderung lokal auszuprobieren:

Diejenigen unter Ihnen mit Adleraugen werden das head am Ende des Remote-Abschnitts der refspec bemerken. Es gibt auch ein refs/pull/#/merge ref auf der GitHub-Seite, der den Commit darstellt, der sich ergeben würde, wenn Sie auf die Schaltfläche „merge“ klicken. Dies kann es Ihnen ermöglichen, das Zusammenführen zu testen, bevor Sie überhaupt auf die Schaltfläche klicken. Auf diese Weise können Sie das Mergen testen, bevor Sie überhaupt auf die Schaltfläche klicken.

Sie können nicht nur Pull-Requests öffnen, die auf den Haupt- oder master Branch gerichtet sind, sondern auch einen Pull-Request, der auf einen beliebigen Branch im Netzwerk ausgerichtet ist. Vielmehr können Sie sogar einen weiteren Pull-Request als Ziel wählen.

Wenn Sie einen Pull-Request sehen, der sich in die richtige Richtung bewegt und Sie eine Idee für eine Änderung haben, die von ihm abhängt; oder Sie sich nicht sicher sind, ob er eine gute Idee ist; oder Sie einfach keinen Push-Zugang zum Zielbranch haben – dann können Sie einen Pull-Request auf diesen direkt öffnen.

Wenn Sie einen Pull-Request öffnen, befindet sich oben auf der Seite ein Feld, das angibt, von welchem Branch Sie pullen und in welchen Sie den Pull-Vorgang ausführen möchten. Wenn Sie auf die Schaltfläche „Edit“ (Bearbeiten), rechts neben diesem Feld, klicken, können Sie nicht nur die Branches, sondern auch den Fork ändern.

Hier können Sie relativ einfach angeben, ob Ihr neuer Branch in einen anderen Pull-Request oder einen anderen Fork des Projekts zusammengeführt werden soll.

Wenn wir hier „Benachrichtigungen“ (engl. notifications) erwähnen, meinen wir wie GitHub versucht Sie zu erreichen, falls ein Ereigniss eintritt. Es gibt ein paar Einstellungen, die Sie konfigurieren können. Wenn Sie von der Settings-Seite aus auf die Registerkarte "Notifications" gehen, sehen Sie einige der verfügbaren Optionen.

Die beiden Möglichkeiten sind: über „E-Mail“ oder „Web“ benachrichtigen. Sie können entweder eine, keine oder beide Optionen wählen, wenn Sie sich an den Aktivitäten in Repositorien beteiligen, die Sie gerade beobachten.

Wenn Sie einen anderen Branch statt „master“ als Standard-Zweig verwenden wollen, auf den die Teilnehmer Pull-Requests öffnen oder ihn standardmäßig sehen sollen, dann können Sie das auf der Settings-Seite Ihres Repositorys unter der Registerkarte „Optionen“ ändern.

Ändern Sie einfach den Standard-Branch in der Dropdown-Liste und das ist dann der Vorgabewert für alle wichtigen Operationen, einschließlich des Branchs, der standardmäßig ausgecheckt wird, wenn jemand das Repository klont.

Wenn Sie ein Projekt auf einen anderen Benutzer oder eine Organisation in GitHub übertragen möchten, gibt es unten auf der gleichen Registerkarte „Optionen“ Ihrer Repository-Einstellungen eine Option „Eigentum übertragen“ (engl. Transfer ownership), die das ermöglicht.

Diese Option ist sinnvoll, wenn Sie ein Projekt aufgeben und es von jemandem übernommen werden soll oder wenn Ihr Projekt größer wird und Sie es in eine Organisation verlagern möchten.

Dadurch wird nicht nur das Repository zusammen mit all seinen Beobachtern und Sternen an einen anderen Ort verschoben, sondern es wird auch ein Redirect von Ihrer URL an den neuen Ort eingerichtet. Es wird auch die Klone und Fetches von Git umleiten, nicht nur die Web-Anfragen.