Wie man einen Pull Request auf GitHub erstellt

Git ist ein Open-Source-distributed Version Control System, das kollaborative Softwareprojekte besser handhabbar macht. Viele Projekte verwalten ihre Dateien in einem Git-Repository, und Plattformen wie GitHub haben das Teilen und Beitragenden von Code zugänglich, wertvoll und effektiv gemacht.

Open-Source-Projekte, die in öffentlichen Repositories gehostet werden, profitieren von Beiträgen der breiteren Entwicklergemeinschaft durch Pull Requests, die darum bitten, dass ein Projekt Änderungen akzeptiert, die Sie an seinem Code-Repository vorgenommen haben.

Dieses Tutorial wird Sie dabei unterstützen, einen Pull Request für ein Git-Repository über die Befehlszeile zu erstellen, damit Sie zu Open-Source-Softwareprojekten beitragen können.

Voraussetzungen

Sie sollten Git auf Ihrem lokalen Rechner installiert haben. Sie können überprüfen, ob Git auf Ihrem Computer installiert ist, und den Installationsprozess für Ihr Betriebssystem durchgehen, indem Sie dieser Anleitung folgen.

Außerdem benötigen Sie ein GitHub-Konto. Sie können dies über die GitHub-Website, github.com, erstellen und sich entweder anmelden oder ein Konto erstellen.

Seit November 2020 hat GitHub die sichere Authentifizierung auf Passwortbasis entfernt. Aus diesem Grund müssen Sie einen persönlichen Zugriffsschlüssel erstellen oder Ihre SSH-Public-Key-Informationen hinzufügen, um über die Befehlszeile auf GitHub-Repositories zugreifen zu können.

Schließlich sollten Sie ein Open-Source-Softwareprojekt identifizieren, zu dem Sie beitragen möchten. Sie können sich mit Open-Source-Projekten vertrauter machen, indem Sie diese Einführung lesen.

Erstellen Sie eine Kopie des Repositories

Ein Repository oder Repo ist im Grunde genommen der Hauptordner eines Projekts. Das Repository enthält alle relevanten Projektdateien, einschließlich der Dokumentation, und speichert auch den Revisionsverlauf für jede Datei. Auf GitHub können Repositories mehrere Mitwirkende haben und entweder öffentlich oder privat sein.

Um an einem Open-Source-Projekt zu arbeiten, müssen Sie zunächst eine Kopie des Repositories erstellen. Dazu sollten Sie das Repository forken und dann klonen, damit Sie eine lokale Arbeitskopie haben.

Forken Sie das Repository

Sie können ein Repository auf GitHub forken, indem Sie mit Ihrem Browser zur GitHub-URL des Open-Source-Projekts navigieren, zu dem Sie beitragen möchten.

GitHub-Repository-URLs verweisen sowohl auf den Benutzernamen des Besitzers des Repositorys als auch auf den Repositorynamen. Zum Beispiel ist DigitalOcean Community (Benutzername: do-community) der Besitzer des Cloud-Haiku-Projektrepositorys. Die GitHub-URL für dieses Projekt lautet:

https://github.com/do-community/cloud_haiku

In dem obigen Beispiel ist do-community der Benutzername und cloud_haiku ist der Repositoryname.

Sobald Sie das Projekt identifiziert haben, zu dem Sie beitragen möchten, können Sie zur URL navigieren, die folgendermaßen formatiert ist:

https://github.com/benutzername/repository

Oder Sie können das Projekt mithilfe der GitHub-Suchleiste suchen.

Wenn Sie sich auf der Hauptseite des Repositorys befinden, wird auf der rechten oberen Seite der Seite unter Ihrem Benutzer-Symbol eine Schaltfläche “Forken” angezeigt:

Klicken Sie auf die Schaltfläche “Forken”, um den Fork-Vorgang zu starten. In Ihrem Browserfenster erhalten Sie eine Benachrichtigung, dass das Repository, das Sie forken, verarbeitet wird:

Sobald der Vorgang abgeschlossen ist, gelangen Sie auf einen Bildschirm, der dem vorherigen Repository-Bildschirm ähnelt, außer dass oben Ihrem Benutzernamen vor dem Repositorynamen angezeigt wird und in der URL auch Ihr Benutzername vor dem Repositorynamen angezeigt wird.

Also sehen Sie in dem obigen Beispiel anstelle von “do-community / cloud_haiku” oben auf der Seite “Ihr-Benutzername / cloud_haiku” und die neue URL wird ähnlich wie folgt lauten:

https://github.com/ihre-benutzername/cloud_haiku

Mit dem geforkten Repository sind Sie bereit, es zu klonen, um eine lokale Arbeitskopie des Codes zu haben.

Klonen Sie das Repository

Um eine lokale Kopie des Repositorys zu erstellen, zu dem Sie beitragen möchten, öffnen wir zuerst ein Terminalfenster.

Wir verwenden den Befehl git clone zusammen mit der URL, die auf Ihren Fork des Repositorys zeigt.

Diese URL ähnelt der obigen URL, endet jedoch jetzt mit .git. Im obigen Beispiel für cloud_haiku lautet die URL ähnlich wie folgt, wobei Sie Ihren tatsächlichen Benutzernamen anstelle von ihre-benutzername verwenden:

https://github.com/ihre-benutzername/cloud_haiku.git

Sie können alternativ die URL kopieren, indem Sie die grüne Schaltfläche “⤓ Code” auf Ihrer Repository-Seite verwenden, von der Sie den Fork ursprünglich gemacht haben. Sobald Sie auf die Schaltfläche klicken, können Sie die URL kopieren, indem Sie auf die Schaltfläche “Zwischenablage” neben der URL klicken:

Sobald wir die URL haben, sind wir bereit, das Repository zu klonen. Dazu kombinieren wir den Befehl git clone mit der Repository-URL aus der Befehlszeile in einem Terminalfenster:

git clone https://github.com/ihre-benutzername/repository.git

Jetzt, da wir eine lokale Kopie des Codes haben, können wir einen neuen Branch erstellen, auf dem wir mit dem Code arbeiten können.

Erstellen Sie einen neuen Branch

Wenn Sie an einem kollaborativen Projekt arbeiten, haben Sie und andere Entwickler, die zum Repository beitragen, gleichzeitig unterschiedliche Ideen für neue Funktionen oder Fixes. Einige dieser neuen Funktionen erfordern möglicherweise nicht viel Zeit zur Implementierung, andere hingegen sind aufwändiger. Aus diesem Grund ist es wichtig, das Repository zu branchen, damit Sie den Workflow verwalten, Ihren Code isolieren und kontrollieren können, welche Funktionen in den Hauptzweig des Projekt-Repositorys zurückkehren.

Der Hauptzweig eines Projekt-Repositorys wird normalerweise als Hauptzweig bezeichnet. Eine empfohlene Praxis besteht darin, alles im Hauptzweig als bereit zur Verwendung durch andere zu betrachten.

Beim Erstellen eines Branches auf Basis des vorhandenen Projekts ist es sehr wichtig, dass Sie Ihren neuen Branch vom Hauptzweig abzweigen. Sie sollten auch sicherstellen, dass der Branch-Name eine beschreibende ist. Anstatt ihn “mein-branch” zu nennen, sollten Sie “frontend-hook-migration” oder “fix-documentation-typos” wählen.

Um den Branch aus unserem Terminalfenster zu erstellen, ändern wir unser Verzeichnis, damit wir im Verzeichnis des Repositorys arbeiten. Verwenden Sie dabei den tatsächlichen Namen des Repositorys (wie “cloud_haiku”), um in dieses Verzeichnis zu wechseln.

cd repository

Jetzt erstellen wir unseren neuen Branch mit dem Befehl git branch. Achten Sie darauf, ihn aussagekräftig zu benennen, damit andere, die am Projekt arbeiten, verstehen, woran Sie arbeiten.

git branch neuer-branch

Jetzt, da unser neuer Branch erstellt wurde, können wir zu ihm wechseln, um sicherzustellen, dass wir daran arbeiten, indem wir den Befehl git checkout verwenden:

git checkout neuer-branch

Sobald Sie den Befehl git checkout eingegeben haben, erhalten Sie den folgenden Output:

Switched to branch 'neuer-branch'

Alternativ können Sie die beiden obigen Befehle, das Erstellen und Wechseln zu einem neuen Branch, mit dem folgenden Befehl und der -b-Flagge zusammenfassen:

git checkout -b neuer-branch

Wenn Sie zum Hauptzweig wechseln möchten, verwenden Sie den Befehl checkout mit dem Namen des Hauptzweigs:

git checkout main

Der checkout-Befehl ermöglicht Ihnen das Wechseln zwischen mehreren Branches, sodass Sie potenziell an mehreren Funktionen gleichzeitig arbeiten können.

An diesem Punkt können Sie nun vorhandene Dateien ändern oder neue Dateien auf Ihrem eigenen Branch hinzufügen.

Lokale Änderungen vornehmen

Um das Erstellen eines Pull Requests zu demonstrieren, verwenden wir das Beispiel-Repository cloud_haiku und erstellen eine neue Datei in unserer lokalen Kopie. Verwenden Sie Ihren bevorzugten Texteditor, um eine neue Datei zu erstellen, damit wir ein neues Haiku-Gedicht hinzufügen können, wie in den Beitrag-Richtlinien erklärt. Wir können zum Beispiel nano verwenden und unsere Beispiel-Datei filename.md nennen. Sie müssen Ihre Datei mit einem originellen Namen und der .md-Erweiterung für Markdown benennen.

nano filename.md

Als nächstes fügen wir etwas Text zur neuen Datei hinzu, indem wir uns an die Beitrag-Richtlinien halten. Wir müssen das Jekyll-Format verwenden und ein Haiku mit Zeilenumbrüchen hinzufügen. Die folgende Datei ist eine Beispieldatei, Sie müssen jedoch ein originelles Haiku beitragen.

– layout: haiku
  title: Octopus Cloud
  author: Sammy

  Distributed cloud
  Like the octopuses’ minds
  Across the network

Sobald Sie Ihren Text eingefügt haben, speichern und schließen Sie die Datei. Wenn Sie nano verwendet haben, tun Sie dies, indem Sie STRG + X, dann Y und dann ENTER drücken.

Sobald Sie eine vorhandene Datei geändert oder eine neue Datei zum Projekt Ihrer Wahl hinzugefügt haben, können Sie sie zu Ihrem lokalen Repository hinzufügen, was wir mit dem Befehl git add tun können. In unserem Beispiel filename.md geben wir den folgenden Befehl ein.

git add filename.md

Wir geben den Namen der von uns erstellten Datei an diesen Befehl weiter, um sie zu unserem lokalen Repository hinzuzufügen. Dadurch wird sichergestellt, dass Ihre Datei bereit ist, hinzugefügt zu werden.

Wenn Sie alle Dateien, die Sie in einem bestimmten Verzeichnis geändert haben, hinzufügen möchten, können Sie sie alle mit dem folgenden Befehl hinzufügen:

git add .

Hier fügt der Punkt alle relevanten Dateien hinzu.

Wenn Sie alle Änderungen, einschließlich derer in Unterverzeichnissen, rekursiv hinzufügen möchten, können Sie Folgendes eingeben:

git add -A

Alternativ können Sie git add -all eingeben, um alle neuen Dateien zu stagen.

Mit unserer Datei, die zum Stagen bereit ist, nehmen wir nun die Änderungen, die wir am Repository vorgenommen haben, mit dem Befehl git commit auf.

Änderungen committen

Die Commit-Nachricht ist ein wichtiger Aspekt Ihres Code-Beitrags. Sie hilft den Maintainer-Teams und anderen Beitragsleistenden dabei, die von Ihnen vorgenommene Änderung vollständig zu verstehen, warum Sie sie vorgenommen haben und wie bedeutsam sie ist. Darüber hinaus bieten Commit-Nachrichten einen historischen Rekord der Änderungen für das gesamte Projekt, der zukünftigen Beitragsleistenden bei der Arbeit hilft.

Wenn wir eine sehr kurze Nachricht haben, können wir das mit der -m-Flagge und der Nachricht in Anführungszeichen aufzeichnen. In unserem Beispiel für das Hinzufügen eines Haikus könnte unser git commit so ähnlich aussehen wie folgt.

git commit -m “Habe ein neues Haiku in der Datei filename.md hinzugefügt”

Wenn es sich nicht um eine kleine oder erwartete Änderung handelt, möchten wir möglicherweise eine ausführlichere Commit-Nachricht einschließen, damit unsere Mitwirkenden vollständig über unseren Beitrag informiert sind. Um diese umfangreichere Nachricht aufzuzeichnen, führen wir den Befehl git commit aus, der den Standardtexteditor öffnet.

git commit

Wenn Sie diesen Befehl ausführen, bemerken Sie möglicherweise, dass Sie sich im Vim-Editor befinden, den Sie durch Eingabe von :q beenden können. Wenn Sie Ihren Standardtexteditor konfigurieren möchten, können Sie dies mit dem Befehl git config tun und nano beispielsweise als Standardeditor festlegen:

git config --global core.editor "nano"

Oder vim:

git config --global core.editor "vim"

Nachdem Sie den Befehl git commit ausgeführt haben, sollte je nach verwendetem Standardtexteditor Ihr Terminalfenster ein Dokument anzeigen, das bereit ist, von Ihnen bearbeitet zu werden und ähnlich wie folgt aussieht:

# Bitte geben Sie die Commit-Nachricht für Ihre Änderungen ein. Zeilen, die mit '#' beginnen, werden ignoriert, und eine leere Nachricht bricht den Commit ab.
# On branch neuer-branch
# Your branch is up-to-date with 'origin/neuer-branch'.
#
# Changes to be committed:
#       modified:   neues-feature.py

Unterhalb der einführenden Kommentare sollten Sie die Commit-Nachricht zur Textdatei hinzufügen.

Um eine nützliche Commit-Nachricht zu schreiben, sollte die erste Zeile eine Zusammenfassung sein, die etwa 50 Zeichen lang ist. Darunter und in verdaulichen Abschnitten aufgeteilt, sollten Sie eine Beschreibung einschließen, in der der Grund Ihrer Änderung, wie der Code funktioniert, und zusätzliche Informationen, die den Kontext Ihrer Änderung verdeutlichen und klären, für andere überprüft werden. Versuchen Sie, so hilfreich und proaktiv wie möglich zu sein, um sicherzustellen, dass die Wartenden des Projekts Ihren Beitrag vollständig verstehen können.

Änderungen pushen

Nachdem Sie die Commit-Nachricht gespeichert und den Texteditor verlassen haben, können Sie mit dem folgenden Befehl überprüfen, was Git committen wird:

git status

Je nach den vorgenommenen Änderungen erhalten Sie eine Ausgabe, die wie folgt aussieht:

On branch neuer-branch
nothing to commit, working tree clean

An diesem Punkt können Sie den Befehl git push verwenden, um die Änderungen zum aktuellen Branch Ihres geforkten Repositorys zu pushen:

git push --set-upstream origin neuer-branch

Der Befehl gibt Ihnen eine Ausgabe, um Sie über den Fortschritt zu informieren, und sieht ähnlich aus wie folgt:

Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 336 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/ihre-benutzername/repository.git
a1f29a6..79c0e80 neuer-branch -> neuer-branch
Branch neuer-branch set up to track remote branch neuer-branch from origin.

Nun können Sie zu Ihrem GitHub-Webseiten-Forked-Repository navigieren und zum Branch wechseln, den Sie geschoben haben, um die Änderungen, die Sie im Browser vorgenommen haben, zu sehen.

An diesem Punkt ist es möglich, einen Pull Request zum ursprünglichen Repository zu erstellen. Wenn Sie dies jedoch noch nicht getan haben, sollten Sie sicherstellen, dass Ihr lokales Repository mit dem Upstream-Repository auf dem neuesten Stand ist.

Lokales Repository aktualisieren

Wenn Sie an einem Projekt zusammen mit anderen Beitragsleistenden arbeiten, ist es wichtig, dass Sie Ihr lokales Repository mit dem Projekt auf dem neuesten Stand halten, da Sie keinen Pull Request für Code erstellen möchten, der automatisch Konflikte verursacht (obwohl es in kollaborativen Codeprojekten zu Konflikten kommen kann). Um Ihre lokale Kopie des Codebaums auf dem neuesten Stand zu halten, sollten Sie Änderungen synchronisieren.

Zuerst besprechen wir das Konfigurieren eines Remotes für den Fork und dann das Synchronisieren des Forks.

Konfigurieren eines Remotes für den Fork

Remote-Repositories ermöglichen es Ihnen, bei einem Git-Projekt mit anderen zusammenzuarbeiten. Jedes Remote-Repository ist eine Version des Projekts, das im Internet oder in einem Netzwerk gehostet wird, auf das Sie Zugriff haben. Jedes Remote-Repository sollte für Sie entweder als schreibgeschützt oder schreibgeschützt verfügbar sein, abhängig von Ihren Benutzerrechten.

Um Änderungen synchronisieren zu können, die Sie in einem Fork mit dem ursprünglichen Repository vorgenommen haben, müssen Sie einen Remote konfigurieren, der auf das Upstream-Repository verweist. Sie sollten das Remote nur einmal für das Upstream-Repository einrichten.

Lassen Sie uns zuerst überprüfen, welche Remote-Server Sie bereits konfiguriert haben. Der Befehl git remote listet das jeweilige Remote-Repository auf, das Sie bereits angegeben haben. Wenn Sie wie oben beschrieben Ihr Repository geklont haben, sollten Sie zumindest eine Ausgabe in Bezug auf das Origin-Repository erhalten, das der Standardname ist, den Git für das geklonte Verzeichnis verwendet.

Von dem Verzeichnis des Repositorys in unserem Terminalfenster aus verwenden wir den Befehl git remote zusammen mit der Flagge -v, um die URLs anzuzeigen, die Git zusammen mit den relevanten Remote-Kurznamen (wie “origin”) gespeichert hat:

git remote -v

Da wir ein Repository geklont haben, sollte unsere Ausgabe ähnlich wie folgt aussehen:

origin  https://github.com/ihre-benutzername/geforktes-repository.git (fetch)
origin  https://github.com/ihre-benutzername/geforktes-repository.git (push)

Wenn Sie zuvor mehr als ein Remote konfiguriert haben, gibt der Befehl git remote -v eine Liste aller aus.

Als Nächstes geben wir ein neues Remote-Upstream-Repository an, um unseren Fork mit dem ursprünglichen Repository zu synchronisieren. Dies wird das ursprüngliche Repository sein, von dem wir geforkt haben. Wir verwenden den Befehl git remote add dafür.

git remote add upstream https://github.com/ursprünglicher-besitzer-name/ursprüngliches-repository.git

Für unser Beispiel cloud_haiku sieht dieser Befehl folgendermaßen aus:

git remote add upstream https://github.com/do-community/cloud_haiku.git

In diesem Beispiel ist upstream der Kurzname, den wir für das Remote-Repository angegeben haben, da sich “ursprung” in Bezug auf Git auf das Repository bezieht, von dem wir geforkt haben. Wenn Sie einen Remote-Zeiger zum Repository eines Mitwirkenden hinzufügen möchten, möchten Sie möglicherweise den Benutzernamen dieses Mitwirkenden oder eine gekürzte Abkürzung verwenden.

Wir können überprüfen, ob unser Remote-Zeiger zum Upstream-Repository ordnungsgemäß hinzugefügt wurde, indem wir erneut den Befehl git remote -v aus dem Verzeichnis des Repositorys ausführen:

git remote -v

Nun können Sie auf der Befehlszeile auf upstream verweisen, anstatt die gesamte URL zu schreiben, und Sie sind bereit, Ihren Fork mit dem ursprünglichen Repository zu synchronisieren.

Fork synchronisieren

Wenn wir einen Remote konfiguriert haben, der auf das Upstream- und das ursprüngliche Repository auf GitHub verweist, sind wir bereit, unseren Fork des Repositorys zu synchronisieren, um ihn auf dem neuesten Stand zu halten.

Um unseren Fork zu synchronisieren, verwenden wir aus dem Verzeichnis unseres lokalen Repositorys in einem Terminalfenster den Befehl git fetch, um die Branches zusammen mit ihren jeweiligen Commits aus dem Upstream-Repository abzurufen. Da wir den Kurznamen “upstream” verwendet haben, um auf das Upstream-Repository zu verweisen, geben wir diesen an den Befehl weiter.

git fetch upstream

Je nachdem, wie viele Änderungen seit unserem Fork des Repositorys vorgenommen wurden, kann Ihre Ausgabe anders aussehen und einige Zeilen zum Zählen, Komprimieren und Entpacken von Objekten enthalten. Ihre Ausgabe endet ähnlich wie die folgenden Zeilen, kann jedoch je nach Anzahl der im Projekt vorhandenen Branches variieren:

From https://github.com/ursprünglicher-besitzer-name/ursprüngliches-repository
 * [new branch]      main       -> upstream/main

Nun werden Commits im Hauptzweig in einem lokalen Branch mit dem Namen upstream/main gespeichert.

Lassen Sie uns zum lokalen Hauptzweig unseres Repositorys wechseln:

git checkout main

Nun verschmelzen wir alle Änderungen, die im Hauptzweig des ursprünglichen Repositorys vorgenommen wurden und auf die wir über unseren lokalen Branch upstream/main zugreifen, mit unserem lokalen Hauptzweig:

git merge upstream/main

Die Ausgabe hier wird variieren, aber sie wird mit “Updating” beginnen, wenn Änderungen vorgenommen wurden, oder mit “Already up-to-date.”, wenn seit dem Fork des Repositorys keine Änderungen vorgenommen wurden.

Der Hauptzweig Ihres Forks ist nun mit dem Upstream-Repository synchronisiert, und alle lokalen Änderungen, die Sie vorgenommen haben, sind nicht verloren gegangen.

Je nach Ihrem eigenen Arbeitsablauf und der Zeit, die Sie für Änderungen aufwenden, können Sie Ihren Fork mit dem Upstream-Code des ursprünglichen Repositorys aktualisieren, so oft es für Sie sinnvoll ist. Sie sollten jedoch Ihren Fork unbedingt direkt vor dem Erstellen eines Pull Requests synchronisieren, um sicherzustellen, dass Sie keinen konfligierenden Code beitragen.

Pull Request erstellen

An diesem Punkt sind Sie bereit, einen Pull Request an das ursprüngliche Repository zu senden.

Sie sollten zu Ihrem geforkten Repository navigieren und auf der linken Seite des Bildschirms die Schaltfläche “Neuer Pull Request” drücken.

Sie können den Branch auf dem nächsten Bildschirm ändern. Auf beiden Seiten können Sie das entsprechende Repository aus dem Dropdown-Menü auswählen und den entsprechenden Branch auswählen.

Sobald Sie beispielsweise den Hauptzweig des ursprünglichen Repositorys auf der linken Seite und den neuen Branch Ihres Repositorys auf der rechten Seite ausgewählt haben, erhalten Sie einen Bildschirm, auf dem angegeben wird, dass Ihre Branches zusammengeführt werden können, sofern kein konkurrierender Code vorhanden ist:

Sie sollten einen Titel und einen Kommentar in die entsprechenden Felder eingeben und dann die Schaltfläche “Pull Request erstellen” drücken.

An diesem Punkt werden die Maintainer des ursprünglichen Repositorys entscheiden, ob sie Ihren Pull Request akzeptieren oder nicht. Sie können Sie bitten, Ihren Code vor der Annahme des Pull Requests zu bearbeiten oder zu überarbeiten.

Fazit

An diesem Punkt haben Sie erfolgreich einen Pull Request an ein Open-Source-Software-Repository gesendet. Im Anschluss sollten Sie sicherstellen, dass Sie Ihren Code während des Wartens auf eine Überprüfung aktualisieren und rebaseen. Die Projektwartenden können Sie bitten, Ihren Code zu überarbeiten, daher sollten Sie darauf vorbereitet sein.

Zur Teilnahme an Open-Source-Projekten und zum aktiven Open-Source-Entwickler zu werden, kann eine lohnende Erfahrung sein. Durch regelmäßige Beiträge zu Software, die Sie häufig verwenden, können Sie sicherstellen, dass diese Software für andere Endbenutzer so wertvoll wie möglich ist.

Wenn Sie an Git und der Zusammenarbeit an Open-Source-Software interessiert sind, können Sie unsere Tutorial-Serie mit dem Titel “Eine Einführung in Open Source” lesen. Wenn Sie bereits mit Git vertraut sind und eine Spickzettel benötigen, können Sie sich “Wie verwendet man Git: Eine Referenzanleitung” ansehen.