6.3 GitHub - Ein Projekt betreuen

Irgendjemand bearbeitet deinen Code und sendet dir einen Pull-Request. In diesem Fall solltest du eine E-Mail erhalten, in der du über den neuen Pull-Request informiert wirst. 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 wie sehr sie sich geändert haben. Du erhältst einen Link zum Pull Request auf GitHub. Du erhältst auch ein paar URLs, die du von der Kommandozeile aus verwenden kannst.

Wenn du die Zeile siehst, 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 du möchtest, kannst du einen Feature-Branch erstellen und in diesen wechseln (engl. checkout). Anschließend kannst du 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 du vielleicht vermutest, vereinheitlichte Diff- und Patch-Versionen des Pull Requests bereitstellen. Technisch gesehen kannst du die Arbeit im Pull-Request mit einem Befehl wie diesem zusammenführen:

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

Jedes Mal, wenn jemand den Pull-Request kommentiert, erhältst du weitere E-Mail-Benachrichtigungen, damit du weißt, dass Aktivitäten stattfinden. Du wirst jeweils einen Link zum Pull Request erhalten, in dem die Aktivität stattfindet. Auf die E-Mails kannst du auch direkt antworten, um den Pull-Request-Thread zu kommentieren.

Sobald der Quellcode soweit korrekt ist und du ihn zusammenführen möchtest, kannst du ihn mit der Anweisung git pull <url> <branch> (wie zuvor gesehen) pullen und lokal mergen. Oder du fügst den Fork als Remote hinzu, fetchst den Patch und mergst ihn anschließend.

Wenn das Zusammenführen trivial ist, kannst du 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 du tust, jedes Mal, wenn du auf die Schaltfläche Merge klickst, ein Merge-Commit erstellt wird. Wie du in Merge-Button und Anweisungen zum manuellen Zusammenführen eines Pull-Requests sehen kannst, gibt dir GitHub all diese Informationen, wenn du auf den Hinweis-Link klickst.

Wenn du dich entscheidest, dass du ihn nicht zusammenführen möchtest, kannst du auch einfach den Pull-Request schließen und die Person, die ihn geöffnet hat, wird benachrichtigt.

Wenn du m< viele Pull-Requests erhältst und nicht jedes Mal einen ganzen Batzen Remotes hinzufügen oder einmalige Pulls durchführen willst, gibt es einen tollen Kniff in GitHub. Es handelt sich um einen fortgeschrittenen Trick, den wir in Kapitel 10, Refspecs ausführlicher durchgehen werden. Er kann jedoch recht nützlich sein.

GitHub beschreibt die Pull-Request-Branches für ein Repository als eine Art Pseudo-Branch auf dem Server. Normalerweise werden sie beim Klonen nicht angezeigt- Sie sind jedoch verdeckt vorhanden und man kann recht einfach darauf zugreifen.

Um das zu verdeutlichen, werden wir den Low-Level-Befehl ls-remote verwenden, der oft als Git-Basisbefehl (engl. plumbing) 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 du dich in deinem Repository befindest und git ls-remote origin ausführst (oder auch einen beliebigen anderen Remote, den du überprüfen möchtest), dann sieht die Ausgabe ähnlich aus.

Wenn sich das Repository auf GitHub befindet und es offnee Pull-Requests gibt, 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 du klonst oder vom Server fetchst – 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 im 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 Branch (weil der in seinem Fork liegt). Wir haben jedoch pull/<pr#>/head, der auf a5a775 zeigt. Das heißt, wir können jeden Pull-Request-Branch herunterladen, ohne lokal einen Menge Remotes hinzufügen zu müssen.

Jetzt kannst du das Fetchen dieser Referenz direkt durchführen.

Damit sagt man Git: „Verbinde dich mit dem origin Remote und laden die Referenz refs/pull/958/head herunter.“ Git macht das mit Vergnügen und lädt alles herunter, was du brauchst, um diesen Ref zu erstellen. Es setzt einen Zeiger auf den Commit, den du unter .git/FETCH_HEAD haben willst. Du kannst die Bearbeitung mit git merge FETCH_HEAD in einen Branch fortsetzen. In diesem könntest du die Änderung testen. Die Merge-Commit-Nachricht sieht jedoch ein wenig merkwürdig aus. Wenn du viele Pull-Requests überprüfen musst, wird das etwas umständlich.

Es gibt auch eine Möglichkeit wie du alle Pull-Requests abrufen und aktuell halten kannst, wann immer du dich mit dem Remote verbindest. Öffne .git/config in deinem bevorzugten Editor und suche nach dem origin Remote. Es sollte etwa so aussehen:

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

Diese letzte Zeile sagt Git: „Alle Referenzen, die wie refs/pull/123/head aussehen, sollten lokal als refs/remotes/origin/pr/123 gespeichert werden.“ Wenn du diese Änderung speicherst und ein git fetch ausführst, 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 du ein Fetch durchführst. Dadurch ist es besonders einfach, den Code aus einer Pull-Anforderung lokal auszuprobieren:

Diejenigen mit Adleraugen unter euch werden das head am Ende des Remote-Abschnitts der refspec bemerkt haben. Es gibt auch ein refs/pull/#/merge ref auf der GitHub-Seite, der den Commit darstellt, der sich ergeben würde, wenn du auf die Schaltfläche „merge“ klickst. Auf diese Weise kannst du das Ergebnis des Pull-Requests testen, bevor du überhaupt auf die Schaltfläche geklickt hast.

Du kannst nicht nur Pull-Requests öffnen, die auf den Haupt- oder master Branch zeigen. Du kannst Pull-Request, gegen jeden beliebigen Branch im Netzwerk stellen. Du kannst sogar einen anderen Pull-Request als Ziel wählen.

Wenn du einen Pull-Request siehst, der dir gefällt und du eine Idee für eine Änderung hast, die von ihm abhängt; oder du dir nicht sicher bist, ob dieser Pull-Request überhaupt eine gute Idee ist; oder du keine Push-Berechtigung zum Zie-Branch hast – kannst du einen Pull-Request auf diesen anderen Pull-Request öffnen.

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

Hier kannst du relativ einfach angeben, ob dein neuer Branch in einen anderen Pull-Request oder in einen anderen Fork des Projekts zusammengeführt werden soll.

Wenn wir hier „Benachrichtigungen“ (engl. notifications) erwähnen, meinen wir wie GitHub versucht dich zu informieren, falls ein Ereignis eintritt. Es gibt ein paar Einstellungen, die du konfigurieren kannst. Wenn du von der Settings-Seite aus auf die Registerkarte "Notifications" gehst, siehst du einige der verfügbaren Optionen.

Die beiden Möglichkeiten sind: über „E-Mail“ oder „Web“ benachrichtigen. Du kannst entweder eine, keine oder beide Optionen wählen, wenn du dich an den Aktivitäten in Repositorys beteiligst, die du gerade beobachtest.

Wenn du einen anderen Branch als „master“ als Standard-Branch verwenden willst, auf den die Teilnehmer Pull-Requests öffnen oder ihn standardmäßig sehen sollen, dann kannst du das auf der Settings-Seite deines Repositorys unter der Registerkarte „Optionen“ ändern.

Ändere 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 du ein Projekt auf einen anderen Benutzer oder eine Organisation in GitHub übertragen möchtest, gibt es unten auf der gleichen Registerkarte „Optionen“ deiner Repository-Einstellungen eine Option „Eigentum übertragen“ (engl. Transfer ownership), die das ermöglicht.

Diese Option ist sinnvoll, wenn du ein Projekt aufgibst und es von jemandem übernommen werden soll oder wenn dein Projekt größer wird und du es in eine andere Organisation verlagern möchtest.

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 deiner URL an den neuen Ort eingerichtet. Es wird auch die Klone und Fetches von Git umleiten, nicht nur die Web-Anfragen.