6.3 GitHub - Ein Projekt verwalten

Jemand macht eine Änderung an Ihrem Code und sendet Ihnen eine Pull-Anfrage. Sie sollten eine E-Mail erhalten, die Sie über die neue Pull-Anfrage benachrichtigt, und sie sollte ungefähr so aussehen wie E-Mail-Benachrichtigung über eine neue Pull-Anfrage.

In dieser E-Mail gibt es ein paar Dinge zu beachten. Sie erhalten einen kleinen Diffstat – eine Liste der geänderten Dateien in der Pull-Anfrage und wie stark sie geändert wurden. Sie erhalten einen Link zur Pull-Anfrage auf GitHub. Außerdem erhalten Sie einige URLs, die Sie von der Befehlszeile aus verwenden können.

Wenn Sie die Zeile git pull <url> patch-1 sehen, ist dies eine einfache Möglichkeit, einen Remote-Branch zusammenzuführen, ohne einen Remote hinzufügen zu müssen. Wir haben dies kurz in Remote-Branches auschecken besprochen. Wenn Sie möchten, können Sie einen Themen-Branch erstellen und zu diesem wechseln und dann diesen Befehl ausführen, um die Änderungen der Pull-Anfrage zusammenzuführen.

Die anderen interessanten URLs sind die .diff und .patch URLs, die, wie Sie sich vielleicht denken können, einheitliche Diff- und Patch-Versionen der Pull-Anfrage bereitstellen. Sie könnten technisch gesehen die Arbeit an der Pull-Anfrage mit etwas wie diesem zusammenführen

Wie wir in Der GitHub Flow besprochen haben, können Sie nun ein Gespräch mit der Person führen, die die Pull-Anfrage geöffnet hat. Sie können spezifische Codezeilen, ganze Commits oder die gesamte Pull-Anfrage selbst kommentieren, wobei überall GitHub Flavored Markdown verwendet wird.

Jedes Mal, wenn jemand anderes die Pull-Anfrage kommentiert, erhalten Sie weiterhin E-Mail-Benachrichtigungen, damit Sie wissen, dass Aktivität stattfindet. Jede dieser Benachrichtigungen enthält einen Link zur Pull-Anfrage, auf der die Aktivität stattfindet, und Sie können auch direkt auf die E-Mail antworten, um den Thread der Pull-Anfrage zu kommentieren.

Sobald der Code an einem Ort ist, der Ihnen gefällt und den Sie zusammenführen möchten, können Sie ihn entweder herunterladen und lokal zusammenführen, entweder mit der git pull <url> <branch> Syntax, die wir zuvor gesehen haben, oder indem Sie den Fork als Remote hinzufügen und abrufen und zusammenführen.

Wenn die Zusammenführung trivial ist, können Sie auch einfach auf die Schaltfläche "Zusammenführen" auf der GitHub-Website klicken. Dies führt eine "non-fast-forward"-Zusammenführung durch, wodurch ein Zusammenführungs-Commit erstellt wird, auch wenn eine "fast-forward"-Zusammenführung möglich war. Das bedeutet, dass jedes Mal, wenn Sie auf die Schaltfläche "Zusammenführen" klicken, ein Zusammenführungs-Commit erstellt wird. Wie Sie in Schaltfläche "Zusammenführen" und Anweisungen zum manuellen Zusammenführen einer Pull-Anfrage sehen können, gibt Ihnen GitHub all diese Informationen, wenn Sie auf den Hinweislunk klicken.

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

Wenn Sie mit **vielen** Pull-Anfragen zu tun haben und nicht jedes Mal eine Reihe von Remotes hinzufügen oder einmalige Pushes durchführen möchten, gibt es einen cleveren Trick, den GitHub Ihnen erlaubt. Dies ist ein etwas fortgeschrittener Trick, und wir werden uns die Details davon in Die Refspec genauer ansehen, aber er kann sehr nützlich sein.

GitHub wirbt die Pull-Anfragen-Branches eines Repositorys als eine Art Pseudo-Branches auf dem Server an. Standardmäßig erhalten Sie diese beim Klonen nicht, aber sie sind auf eine verschleierte Weise vorhanden und Sie können sie ziemlich einfach abrufen.

Um dies zu demonstrieren, werden wir einen Low-Level-Befehl verwenden (oft als "Plumbing"-Befehl bezeichnet, über den wir in Plumbing und Porcelain mehr lesen werden), namens ls-remote. Dieser Befehl wird im täglichen Git-Betrieb im Allgemeinen nicht verwendet, ist aber nützlich, um uns zu zeigen, welche Referenzen auf dem Server vorhanden sind.

Wenn wir diesen Befehl gegen das "blink"-Repository ausführen, das wir zuvor verwendet haben, erhalten wir eine Liste aller Branches und Tags und anderer Referenzen im Repository.

Natürlich, wenn Sie sich in Ihrem Repository befinden und git ls-remote origin oder einen anderen Remote ausführen, den Sie überprüfen möchten, wird etwas Ähnliches wie dies angezeigt.

Wenn sich das Repository auf GitHub befindet und Sie Pull-Anfragen haben, die geöffnet wurden, erhalten Sie diese Referenzen, die mit refs/pull/ beginnen. Dies sind im Grunde Branches, aber da sie nicht unter refs/heads/ stehen, erhalten Sie sie normalerweise nicht beim Klonen oder Abrufen vom Server – der Abrufprozess ignoriert sie normalerweise.

Es gibt zwei Referenzen pro Pull-Anfrage – diejenige, die auf /head endet, zeigt auf denselben Commit wie der letzte Commit im Pull-Anfragen-Branch. Wenn also jemand eine Pull-Anfrage in unserem Repository öffnet und sein Branch bug-fix heißt und auf den Commit a5a775 zeigt, dann haben wir in **unserem** Repository keinen bug-fix-Branch (da dieser in seinem Fork ist), aber wir **haben** pull/<pr#>/head, das auf a5a775 zeigt. Das bedeutet, dass wir ziemlich einfach jeden Pull-Anfragen-Branch auf einmal abrufen können, ohne eine Reihe von Remotes hinzufügen zu müssen.

Nun könnten Sie so etwas wie das direkte Abrufen der Referenz tun.

Dies sagt Git: "Verbinde dich mit dem origin Remote und lade die Referenz namens refs/pull/958/head herunter." Git gehorcht gerne und lädt alles herunter, was Sie benötigen, um diese Referenz zu konstruieren, und platziert einen Zeiger auf den gewünschten Commit unter .git/FETCH_HEAD. Sie können dies mit git merge FETCH_HEAD in einen Branch, den Sie testen möchten, fortsetzen, aber die Commit-Nachricht für die Zusammenführung sieht etwas seltsam aus. Außerdem wird dies mühsam, wenn Sie **viele** Pull-Anfragen überprüfen.

Es gibt auch eine Möglichkeit, *alle* Pull-Anfragen abzurufen und sie auf dem neuesten Stand zu halten, wenn Sie sich mit dem Remote verbinden. Öffnen Sie .git/config in Ihrem bevorzugten Editor und suchen Sie nach dem origin Remote. Es sollte ungefähr so aussehen

Diese Zeile, die mit fetch = beginnt, ist ein "Refspec". Es ist eine Möglichkeit, Namen auf dem Remote mit Namen in Ihrem lokalen .git-Verzeichnis zuzuordnen. Dieser spezielle Refspec sagt Git: "Die Dinge auf dem Remote, die sich unter refs/heads befinden, sollten in meinem lokalen Repository unter refs/remotes/origin abgelegt werden." Sie können diesen Abschnitt ändern, um einen weiteren 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." Jetzt, wenn Sie diese Datei speichern und ein git fetch ausführen

Jetzt sind alle Remote-Pull-Anfragen lokal mit Referenzen dargestellt, die sich wie Tracking-Branches verhalten; sie sind schreibgeschützt und werden aktualisiert, wenn Sie einen Fetch durchführen. Das macht es super einfach, den Code einer Pull-Anfrage lokal auszuprobieren

Die scharfen Augen unter Ihnen würden das head am Ende des Remote-Teils des Refspecs bemerken. Auf der GitHub-Seite gibt es auch eine Referenz refs/pull/#/merge, die den Commit darstellt, der entstehen würde, wenn Sie auf der Website auf die Schaltfläche "Zusammenführen" klicken. Dies ermöglicht es Ihnen, die Zusammenführung zu testen, bevor Sie überhaupt auf die Schaltfläche klicken.

Sie können nicht nur Pull-Anfragen öffnen, die auf den Haupt- oder master-Branch abzielen, sondern Sie können tatsächlich eine Pull-Anfrage öffnen, die auf jeden Branch im Netzwerk abzielt. Tatsächlich können Sie sogar eine andere Pull-Anfrage anvisieren.

Wenn Sie eine Pull-Anfrage sehen, die sich in die richtige Richtung bewegt, und Sie eine Idee für eine Änderung haben, die davon abhängt, oder Sie sich nicht sicher sind, ob es eine gute Idee ist, oder Sie einfach keinen Push-Zugriff auf den Ziel-Branch haben, können Sie eine Pull-Anfrage direkt an diese öffnen.

Wenn Sie eine Pull-Anfrage öffnen, gibt es oben auf der Seite ein Feld, das angibt, auf welchen Branch Sie ziehen möchten und von welchem Sie ziehen möchten. Wenn Sie auf die Schaltfläche "Bearbeiten" rechts neben diesem Feld klicken, können Sie nicht nur die Branches, sondern auch den Fork ändern.

Hier können Sie ziemlich einfach festlegen, Ihren neuen Branch in eine andere Pull-Anfrage oder einen anderen Fork des Projekts zusammenzuführen.

Wenn wir hier von "Benachrichtigungen" im Zusammenhang mit GitHub sprechen, meinen wir eine spezielle Art und Weise, wie GitHub versucht, Sie zu kontaktieren, wenn Ereignisse eintreten, und es gibt verschiedene Möglichkeiten, diese zu konfigurieren. Wenn Sie im Einstellungsmenü zum Tab "Benachrichtigungszentrale" gehen, können Sie einige der Ihnen zur Verfügung stehenden Optionen sehen.

Die beiden Optionen sind Benachrichtigungen per "E-Mail" und per "Web" zu erhalten, und Sie können entweder, keines von beiden oder beides wählen, wenn Sie aktiv an Dingen teilnehmen und für Aktivitäten in Repositories, die Sie beobachten.

Wenn Sie einen anderen Branch als "master" als Standard-Branch verwenden, auf den Leute Pull-Anfragen öffnen oder den sie standardmäßig sehen sollen, können Sie dies auf der Einstellungsseite Ihres Repositorys unter dem Tab "Optionen" ändern.

Ändern Sie einfach den Standard-Branch im Dropdown-Menü, und dies wird von da an der Standard für alle wichtigen Operationen sein, einschließlich des Branches, der standardmäßig ausgecheckt wird, wenn jemand das Repository klont.

Wenn Sie ein Projekt an einen anderen Benutzer oder eine Organisation auf GitHub übertragen möchten, gibt es unter dem Tab "Optionen" derselben Einstellungsseite Ihres Repositorys eine Option "Besitz übertragen", die Ihnen dies ermöglicht.

Dies ist hilfreich, wenn Sie ein Projekt aufgeben und jemand es übernehmen möchte, oder wenn Ihr Projekt wächst und Sie es in eine Organisation verschieben möchten.

Dies verschiebt nicht nur das Repository mit all seinen Beobachtern und Sternen an einen anderen Ort, sondern richtet auch eine Weiterleitung von Ihrer URL zum neuen Ort ein. Es leitet auch Klone und Abrufe von Git um, nicht nur Webanfragen.