Ablauf eines Pull Request

Der von Godot verwendete sogenannte "PR-Arbeitsablauf" (PR für Pull Request) wird von vielen Projekten auf Git genutzt und sollte erfahrenen Entwicklern freier Software vertraut sein. Die Idee ist, dass nur eine kleine Anzahl Entwickler (wenn überhaupt) Änderungen direkt in den master-Zweig übergeben. Stattdessen spalten (fork) die Mitwirkenden das Projekt (d.h. erstellen eine Kopie davon, die sie nach Belieben ändern können) und fordern dann über die GitHub-Schnittstelle ein pull (Änderungen ziehen) von einem Zweig ihres Fork zu einem Zweig des Originals an ( oft als Upstream bezeichnet).

Die resultierende Pull-Anfrage (PR) kann dann von anderen Mitwirkenden überprüft werden, die sie möglicherweise genehmigen, ablehnen oder meistens Änderungen anfordern. Nach der Genehmigung kann der PR von einem der Kernentwickler zusammengeführt werden, und seine Commits (der neue Code) werden Teil des Zielzweigs (normalerweise des Master-Zweigs).

Wir werden gemeinsam ein Beispiel durchgehen, um den typischen Arbeitsablauf und die zugehörigen Git-Befehle zu zeigen. Aber zuerst werfen wir einen kurzen Blick auf die Organisation von Godots Git-Repository.

Git Quell-Repository

Das Repository auf GitHub ist ein Git Code-Repository zusammen mit einem eingebetteten Problem-Tracker und einem PR-System.

Bemerkung

Zusätzlich zu dieser Dokumentation möchten Sie vielleicht auch einen Blick auf die verschiedenen Godot-Demoprojekte werfen.

Das Git-Versionskontrollsystem ist das Tool, mit dem aufeinanderfolgende Änderungen am Quellcode verfolgt werden. Um einen effizienten Beitrag zu Godot zu leisten, wird dringend empfohlen, die Grundlagen der Git-Befehlszeile zu erlernen. Es gibt einige grafische Oberflächen für Git, aber sie ermutigen Benutzer normalerweise, schlechte Gewohnheiten in Bezug auf den Git- und PR-Ablauf anzunehmen. Wir empfehlen daher, diese nicht zu verwenden. Insbesondere empfehlen wir, den Online-Editor von GitHub nicht für Code-Beiträge zu verwenden (obwohl er für kleine Korrekturen oder Dokumentationsänderungen toleriert wird), da er ein Commit pro Datei und pro Änderung erzwingt, was schnell zu PRs mit einem unlesbaren Git-Verlauf führt (insbesondere nach einer Peer Rezension).

Siehe auch

The first sections of Git's "Book" are a good introduction to the tool's philosophy and the various commands you need to master in your daily workflow. You can read them online on the Git SCM website. You can also try out GitHub's interactive guide.

Die Zweige im Git-Repository sind wie folgt organisiert:

• Im Master-Zweig findet die Entwicklung der nächsten Hauptversion statt. Als Entwicklungszweig kann es instabil sein und ist nicht für den Einsatz in der Produktion vorgesehen. Hier sollten PRs vorrangig durchgeführt werden.

• The stable branches are named after their version, e.g. 3.1 and 2.1. They are used to backport bugfixes and enhancements from the master branch to the currently maintained stable release (e.g. 3.1.2 or 2.1.6). As a rule of thumb, the last stable branch is maintained until the next minor version (e.g. the 3.0 branch was maintained until the release of Godot 3.1). If you want to make PRs against a maintained stable branch, please check first if your changes are also relevant for the master branch, and if so make the PR for the master branch in priority. Release managers can then cherry-pick the fix to a stable branch if relevant.

• Es kann gelegentlich Feature-Zweige geben, die normalerweise zu einem bestimmten Zeitpunkt in den master-Zweig integriert werden sollen.

Forking und Cloning

Der erste Schritt besteht darin, das godotengine/godot repository auf GitHub abzuspalten (englisch Fork). Dazu benötigen Sie ein GitHub-Konto und müssen angemeldet sein. In der oberen rechten Ecke der GitHub-Seite des Repositorys sollten Sie die Schaltfläche "Fork" wie unten gezeigt sehen:

Klicken Sie darauf und nach einer Weile sollten Sie mit Ihrem GitHub-Benutzernamen als Namensraum zu Ihrer eigenen Abzweigung des Godot-Repos weitergeleitet werden:

Sie können dann Ihren abgespalteten Zweig (Fork) klonen, d.h. eine lokale Kopie des Online-Repositorys erstellen (in Git-Sprache den entfernten Ursprung). Wenn Sie dies noch nicht getan haben, laden Sie Git von der Website <https://git-scm.com> `_ herunter, wenn Sie Windows oder MacOS verwenden oder installieren Sie es über Ihren Paketmanager, wenn Sie Linux verwenden.

Bemerkung

Wenn Sie unter Windows arbeiten, öffnen Sie Git Bash um Befehle einzugeben. Benutzer von MacOS und Linux können ihre jeweiligen Terminals verwenden.

Verwenden Sie den folgenden Befehl, um Ihren Fork von GitHub zu klonen:

$ git clone https://github.com/USERNAME/godot

Bemerkung

In unseren Beispielen kennzeichnet das Zeichen "$" die Eingabeaufforderung in typischen UNIX-Shells. Es ist nicht Teil des Befehls und sollte nicht eingegeben werden.

Nach einer Weile sollten Sie ein Godot-Verzeichnis in Ihrem aktuellen Arbeitsverzeichnis haben, in das Sie mit dem Befehl cd hineinwechseln können:

$ cd godot

Wir beginnen mit der Einrichtung eines Verweises auf das ursprüngliche Repository, das wir abspaltet haben:

$ git remote add upstream https://github.com/godotengine/godot
$ git fetch upstream

Dadurch wird eine Referenz mit dem Namen Upstream erstellt, die auf das ursprüngliche Godotengine/Godot-Repository verweist. Dies ist nützlich, wenn Sie neue Commits aus dem Zweig master ziehen möchten, um Ihren Fork zu aktualisieren. Sie haben eine andere Fernreferenz namens origin, die auf Ihren Fork zeigt (USERNAME/godot).

Sie müssen die obigen Schritte nur einmal ausführen, solange Sie diesen lokalen godot-Ordner behalten (den Sie verschieben können, wenn Sie möchten, die relevanten Metadaten sind in seinem .git-Unterordner versteckt).

Bemerkung

verzweigen, ziehen, codieren, inszenieren, bestätigen, hochschieben, neu bauen... technologisch.

Die ist die allgemeine Vorstellung, die Git-Anfänger von ihrem Workflow haben: viele seltsame Befehle, die durch Kopieren und Einfügen gelernt werden müssen, in der Hoffnung, dass sie wie erwartet funktionieren. Und das ist eigentlich kein schlechter Weg zu lernen, solange Sie neugierig sind und nicht zögern, Ihre Suchmaschine zu befragen, sollten Sie mal nicht weiter wissen. Deshalb geben wir Ihnen die grundlegenden Befehle, die Sie bei der Arbeit in Git wissen sollten.

Im Folgenden nehmen wir als Beispiel an, dass Sie eine Funktion in Godots Projektmanager implementieren möchten, die in der Datei editor/project_manager.cpp codiert ist.

Verzweigungen

Standardmäßig sollte der git clone Sie in den master-Zweig Ihres Forks setzen (Ursprung). Um Ihre eigene Feature-Entwicklung zu starten, erstellen wir einen Feature-Zweig:

# Create the branch based on the current branch (master)
$ git branch better-project-manager

# Change the current branch to the new one
$ git checkout better-project-manager

Dieser Befehl entspricht:

# Change the current branch to a new named one, based on the current branch
$ git checkout -b better-project-manager

Wenn Sie zum Master-Zweig zurückkehren möchten, verwenden Sie:

$ git checkout master

Mit dem Befehl git branch können Sie sehen, auf welchem Zweig Sie sich gerade befinden:

$ git branch
  2.1
* better-project-manager
  master

Stellen Sie sicher, dass Sie immer zum Zweig master zurückkehren, bevor Sie einen neuen Zweig erstellen, da Ihr aktueller Zweig als Basis für den neuen Zweig verwendet wird. Alternativ können Sie nach dem Namen des neuen Zweigs einen benutzerdefinierten Basiszweig angeben:

$ git checkout -b my-new-feature master

Ihren Zweig aktualisieren

Das wäre beim ersten Mal (kurz nachdem Sie das Upstream-Repository geforkt haben) nicht nötig. Wenn Sie jedoch das nächste Mal an etwas arbeiten wollen, werden Sie feststellen, dass der master-Zweig Ihres Forks mehrere Commits hinter dem master-Zweig des Upstreams liegt: Pull-Requests von anderen Mitwirkenden wären in der Zwischenzeit gemergt worden.

Um sicherzustellen, dass es keine Konflikte zwischen der von Ihnen entwickelten Funktion und dem aktuellen Upstream master-Zweig gibt, müssen Sie Ihren Zweig aktualisieren, indem Sie den Upstream-Zweig pullen.

$ git pull --rebase upstream master

Das Argument --rebase stellt sicher, dass alle lokalen Änderungen, die Sie vorgenommen haben, auf den gezogenen Zweig angewendet werden, was normalerweise das ist, was wir in unserem PR Arbeitsablauf wollen. Auf diese Weise werden, wenn Sie einen Pull Request öffnen, Ihre eigenen Commits der einzige Unterschied zum Upstream master Zweig sein.

Beim Rebasen können Konflikte entstehen, wenn Ihre Commits Code ändern, der in der Zwischenzeit im Upstream-Zweig geändert wurde. Wenn das passiert, hält Git beim konfliktbehafteten Commit an und fordert Sie auf, die Konflikte aufzulösen. Sie können dies mit einem beliebigen Texteditor tun, dann die Änderungen stagen (mehr dazu später) und mit git rebase --continue fortfahren. Wiederholen Sie den Vorgang, wenn spätere Commits ebenfalls Konflikte haben, bis die rebase-Operation abgeschlossen ist.

Wenn Sie sich nicht sicher sind, was während eines rebase passiert und Sie in Panik geraten (keine Sorge, das tun wir alle bei den ersten paar Malen), können Sie den rebase mit git rebase --abort abbrechen. Sie sind dann wieder in dem ursprünglichen Zustand Ihres Zweiges, bevor Sie git pull --rebase aufgerufen haben.

Bemerkung

Wenn Sie das Argument --rebase weglassen, erzeugen Sie stattdessen einen Merge-Commit, der Git mitteilt, was es aus den beiden unterschiedlichen Zweigen machen soll. Sollten Konflikte auftreten, würden sie durch diesen Merge-Commit auf einmal aufgelöst werden.

Während dies ein gültiger Arbeitsablauf und das Standardverhalten von git pull ist, sind Merge-Commits innerhalb von PRs in unserem PR-Workflow verpönt. Wir verwenden sie nur beim Zusammenführen von PRs in den Upstream-Zweig.

Die Philosophie ist, dass ein PR die letzte Stufe der Änderungen an der Codebasis darstellen sollte, und wir sind nicht an Fehlern und Korrekturen interessiert, die in Zwischenstufen vor dem Zusammenführen gemacht worden wären. Git gibt uns großartige Werkzeuge, um "die Geschichte umzuschreiben" und es so aussehen zu lassen, als ob wir die Dinge beim ersten Mal richtig gemacht hätten, und wir nutzen sie gerne, um sicherzustellen, dass Änderungen noch lange nach dem Zusammenführen einfach zu überprüfen und zu verstehen sind.

Wenn Sie bereits einen Merge-Commit erstellt haben, ohne rebase zu verwenden, oder andere Änderungen vorgenommen haben, die zu einem unerwünschten Verlauf geführt haben, ist die beste Option, ein interaktives Rebase auf dem Upstream-Zweig zu verwenden. Siehe den Abschnitt für Anweisungen.

Tipp

Wenn Sie zu irgendeinem Zeitpunkt einen lokalen Zweig auf einen bestimmten Commit oder Zweig zurücksetzen wollen, können Sie dies mit git reset --hard <commit ID> oder git reset --hard <remote>/<branch> (z.B. git reset --hard upstream/master) tun.

Seien Sie gewarnt, dass dadurch alle Änderungen entfernt werden, die Sie in diesem Zweig möglicherweise vorgenommen haben. Sollten Sie jemals versehentlich Commits verlieren, verwenden Sie den Befehl git reflog, um die Commit-ID des vorherigen Zustands zu finden, den Sie wiederherstellen möchten, und verwenden Sie diese als Argument von git reset --hard, um zu diesem Zustand zurückzukehren.

Änderungen vornehmen

Sie würden dann Ihre Änderungen an unserer Beispieldatei editor/project_manager.cpp mit Ihrer üblichen Entwicklungsumgebung (Texteditor, IDE usw.) vornehmen.

Standardmäßig sind diese Änderungen unstaged. Der Staging-Bereich ist eine Schicht zwischen Ihrem Arbeitsverzeichnis (wo Sie Ihre Änderungen vornehmen) und dem lokalen Git-Repository (die Commits und alle Metadaten im Ordner .git). Um Änderungen aus dem Arbeitsverzeichnis in das Git-Repository zu bringen, müssen Sie sie mit dem Befehl git add stagen und anschließend mit dem Befehl git commit committen.

Es gibt verschiedene Befehle die Sie kennen sollten, um Ihre aktuelle Arbeit zu überprüfen: bevor Sie sie bereitstellen, während sie bereitgestellt wird und nachdem sie übergeben wurde.

• git diff zeigt Ihnen die aktuellen nicht bereitgestellten Änderungen, d.h. die Unterschiede zwischen Ihrem Arbeitsverzeichnis und dem Bereitstellungsbereich.

• git checkout -- <files> macht die nicht bereitgestellten Änderungen an den angegebenen Dateien rückgängig.

• git add <files> wird die Änderungen an den aufgelisteten Dateien bereitstellen.

• git diff --staged zeigt die aktuell bereitgestellten Änderungen an, d.h. die Unterschiede zwischen dem bereitgestelltem Bereich und dem letzten Commit.

• git reset HEAD <files> wird Änderungen an den aufgelisteten Dateien aufheben.

• git status zeigt Ihnen die aktuell bereitgestellten und nicht bereitgestellten Änderungen.

• git commit schreibt die bereitgestellten Dateien fest. Es wird ein Texteditor geöffnet (Sie können den gewünschten Editor mit der Umgebungsvariablen GIT_EDITOR oder der Einstellung core.editor in Ihrer Git-Konfiguration definieren), damit Sie ein Commit-Protokoll schreiben können. Sie können git commit -m "Cooles Festschreibungsprotokoll" verwenden, um das Protokoll direkt zu schreiben.

• Mit git commit --amend können Sie den letzten Commit mit Ihren aktuellen Änderungen (hinzugefügt mit git add) ergänzen. Dies ist die beste Option, wenn Sie einen Fehler im letzten Commit beheben wollen (Fehler, Tippfehler, Stilprobleme, etc.).

• git log zeigt Ihnen die letzten Commits Ihres aktuellen Zweigs an. Wenn Sie lokale Commits vorgenommen haben, sollten diese ganz oben angezeigt werden.

• Mit git show werden Ihnen die Änderungen des letzten Commits angezeigt. Sie können auch einen Commit-Hash angeben, um die Änderungen für diesen Commit zu sehen.

Das ist eine Menge zum Auswendiglernen! Keine Sorge, schauen Sie einfach auf diesem Spickzettel nach, wenn Sie Änderungen vornehmen müssen, und lernen Sie durch machen.

So könnte die Shell-Historie in unserem Beispiel aussehen:

# It's nice to know where you're starting from
$ git log

# Do changes to the project manager with the nano text editor
$ nano editor/project_manager.cpp

# Find an unrelated bug in Control and fix it
$ nano scene/gui/control.cpp

# Review changes
$ git status
$ git diff

# We'll do two commits for our unrelated changes,
# starting by the Control changes necessary for the PM enhancements
$ git add scene/gui/control.cpp
$ git commit -m "Fix handling of margins in Control"

# Check we did good
$ git log
$ git show
$ git status

# Make our second commit
$ git add editor/project_manager.cpp
$ git commit -m "Add a pretty banner to the project manager"
$ git log

Damit sollten wir zwei neue Commits in unserem better-project-manager-Zweig haben, die nicht im master-Zweig waren. Sie sind aber immer noch nur lokal, der entfernte Zweig kennt sie nicht, ebenso wenig wie das Upstream-Repository.

Änderungen an einen entfernten Rechner übertragen

An dieser Stelle kommt git push ins Spiel. In Git wird ein Commit immer im lokalen Repository durchgeführt (im Gegensatz zu Subversion, wo ein Commit direkt das entfernte Repository verändert). Sie müssen die neuen Commits in einen entfernten Zweig pushen, um sie mit der Welt zu teilen. Die Syntax dafür ist:

$ git push <remote> <local branch>[:<remote branch>]

Der Teil über den Remote-Zweig kann weggelassen werden, wenn Sie möchten, dass er denselben Namen wie der lokale Zweig hat. Dies ist in diesem Beispiel der Fall. Wir werden also Folgendes tun:

$ git push origin better-project-manager

Git wird Sie nach Ihrem Benutzernamen und Kennwort fragen, und die Änderungen werden an Ihr Remote-System gesendet. Wenn Sie die Seite des Forks auf GitHub überprüfen, sollten Sie einen neuen Zweig mit Ihren hinzugefügten Commits sehen.

Pull-Anfrage ausgeben

Wenn Sie den Zweig Ihres Forks auf GitHub laden, sollten Sie eine Zeile sehen, die sagt "Dieser Zweig ist 2 Commits vor godotengine:master. " (und möglicherweise einige Commits dahinter, wenn Ihr master-Zweig nicht mit dem Upstream-Zweig master synchronisiert war).

On that line, there is a "Pull request" link. Clicking it will open a form that will let you issue a pull request on the godotengine/godot upstream repository. It should show you your two commits, and state "Able to merge". If not (e.g. it has way more commits, or says there are merge conflicts), don't create the PR yet, something went wrong. Go to our Godot Contributors Chat and ask for support :)

Verwenden Sie einen eindeutigen Titel für den PR und geben Sie die notwendigen Details im Kommentarbereich an. Sie können Screenshots, GIFs oder gezippte Projekte per Drag & Drop einfügen, falls relevant, um zu zeigen, was Ihre Arbeit implementiert. Klicken Sie auf "Create a pull request", und tadaa!

Pull-Anfrage ändern

Während es von anderen Mitwirkenden überprüft wird, müssen Sie häufig Änderungen an Ihrer noch nicht zusammengeführten PR vornehmen, entweder weil die Mitwirkenden sie angefordert haben oder weil Sie beim Testen selbst Probleme festgestellt haben.

Die gute Nachricht ist, dass Sie eine Pull-Anfrage ändern können, indem Sie einfach auf den Zweig reagieren, von dem aus Sie die Pull-Anfrage gestellt haben. Sie können z.B. ein neues Commit für diesen Zweig erstellen, schieben Sie es an Ihren Fork und die PR wird automatisch aktualisiert:

# Check out your branch again if you had changed in the meantime
$ git checkout better-project-manager

# Fix a mistake
$ nano editor/project_manager.cpp
$ git add editor/project_manager.cpp
$ git commit -m "Fix a typo in the banner's title"
$ git push origin better-project-manager

However, be aware that in our PR workflow, we favor commits that bring the codebase from one functional state to another functional state, without having intermediate commits fixing up bugs in your own code or style issues. Most of the time, we will prefer a single commit in a given PR (unless there's a good reason to keep the changes separate). Instead of authoring a new commit, consider using git commit --amend to amend the previous commit with your fixes. The above example would then become:

# Check out your branch again if you had changed in the meantime
$ git checkout better-project-manager

# Fix a mistake
$ nano editor/project_manager.cpp
$ git add editor/project_manager.cpp
# --amend will change the previous commit, so you will have the opportunity
# to edit its commit message if relevant.
$ git commit --amend
# As we modified the last commit, it no longer matches the one from your
# remote branch, so we need to force push to overwrite that branch.
$ git push --force origin better-project-manager

Der interaktive Rebase

Wenn Sie die obigen Schritte nicht genau befolgt haben, um Änderungen in einen Commit anzuhängen, anstatt Fixup-Commits zu erstellen, oder wenn Sie Ihre Änderungen verfasst haben, ohne unsere Tipps zum Arbeitsablauf und zur Verwendung von Git zu kennen, könnten Prüfer von Ihnen verlangen, Ihren Zweig zu rebasen, um einige oder alle Commits in einen Commit zu vereinen.

In der Tat, wenn einige Commits nach Überprüfungen gemacht wurden, um Fehler, Tippfehler usw. im ursprünglichen Commit zu beheben, sind sie nicht relevant für einen zukünftigen Changelog-Leser, der wissen möchte, was in der Godot-Codebasis passiert ist, oder wann und wie eine bestimmte Datei zuletzt geändert wurde.

Um diese fremden Commits in die Haupt-Commits zu vereinen, müssen wir die Geschichte umschreiben. Richtig, wir haben diese Macht. Sie haben vielleicht gelesen, dass es eine schlechte Praxis ist, und es ist wahr, wenn es um Zweige des Upstream Repos geht. Aber in Ihrem Fork, können Sie machen was Sie wollen, und alles ist erlaubt, um ordentliche PRs zu bekommen :)

Wir werden dazu das interaktive rebase git rebase -i verwenden. Dieser Befehl nimmt eine Commit-ID oder einen Zweignamen als Argument und lässt Sie alle Commits zwischen diesem Commit/Zweig und dem letzten in Ihrem Arbeitszweig, dem sogenannten HEAD, ändern.

While you can give any commit ID to git rebase -i and review everything in between, the most common and convenient workflow involves rebasing on the upstream master branch, which you can do with:

$ git rebase -i upstream/master

Bemerkung

Das Referenzieren von Zweigen in Git ist ein wenig knifflig, wegen der Unterscheidung zwischen entfernten und lokalen Zweigen. Hier ist upstream/master (mit einem /) ein lokaler Zweig, der aus dem master-Zweig des entfernten upstream gezogen wurde.

Interaktive Rebases können nur auf lokalen Zweigen durchgeführt werden, daher ist das / hier wichtig. Da sich der Upstream-Zweig häufig ändert, kann Ihr lokaler upstream/master-Zweig veraltet sein, so dass Sie ihn mit git fetch upstream master aktualisieren können. Im Gegensatz zu git pull --rebase upstream master, das Ihren aktuell ausgecheckten Zweig aktualisieren würde, wird fetch nur die upstream/master-Referenz aktualisieren (die sich von Ihrem lokalen master-Zweig unterscheidet... ja, es ist verwirrend, aber Sie werden sich nach und nach damit vertraut machen).

This will open a text editor (vi by default, see Git docs to configure your favorite one) with something which may look like this:

pick 1b4aad7 Add a pretty banner to the project manager
pick e07077e Fix a typo in the banner's title

Der Editor zeigt auch Anweisungen an, wie Sie auf diese Commits reagieren können. Insbesondere sollte er Ihnen sagen, dass "pick" bedeutet, diesen Commit zu verwenden (nichts zu tun), und dass "squash" und "fixup" verwendet werden können, um den Commit in seinen übergeordneten Commit einzubeziehen. Der Unterschied zwischen "squash" und "fixup" ist, dass "fixup" den Commit-Log des zerquetschten Commits verwirft. In unserem Beispiel sind wir nicht daran interessiert, das Log des "Fix a typo"-Commits zu behalten, also verwenden wir:

pick 1b4aad7 Add a pretty banner to the project manager
fixup e07077e Fix a typo in the banner's title

Nach dem Speichern und Beenden des Editors wird der Rebase durchgeführt. Der zweite Commit wird mit dem ersten verschmolzen, und git log und git show sollten nun bestätigen, dass Sie nur einen Commit mit den Änderungen der beiden vorherigen Commits haben.

Aber! Sie haben die Historie umgeschrieben, und nun sind Ihr lokaler und der entfernte Zweig auseinandergeklafft. In der Tat hat sich Commit 1b4aad7 im obigen Beispiel geändert und daher einen neuen Commit-Hash erhalten. Wenn Sie versuchen, zu Ihrem entfernten Zweig zu pushen, wird er einen Fehler auslösen:

$ git push origin better-project-manager
To https://github.com/akien-mga/godot
 ! [rejected]        better-project-manager -> better-project-manager (non-fast-forward)
error: failed to push some refs to 'https://[email protected]/akien-mga/godot'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.

Das ist ein vernünftiges Verhalten, Git wird Sie keine Änderungen pushen lassen, die entfernte Inhalte überschreiben würden. Aber das ist eigentlich das, was wir hier tun wollen, also müssen wir es erzwingen:

$ git push --force origin better-project-manager

Und tadaa! Git wird fröhlich den entfernten Zweig mit dem ersetzen, was Sie lokal hatten (stellen Sie also sicher, dass es das ist, was Sie wollten, indem Sie git log benutzen). Dies wird auch die PR entsprechend aktualisieren.

Löschen eines Git-Zweigs

Nachdem Ihre Pull-Anfrage zusammengeführt wurde, sollten Sie noch etwas tun: Löschen Sie Ihren Git-Zweig für die PR. Es gibt keine Probleme, wenn Sie Ihren Zweig nicht löschen, aber es wird empfohlen, dies zu tun. Sie müssen dies zweimal tun, einmal für den lokalen Zweig und einmal für den Remote-Zweig auf GitHub.

Verwenden Sie diesen Befehl, um unseren besseren Projektmanager-Zweig lokal zu löschen:

$ git branch -d better-project-manager

Alternativ, wenn der Zweig noch nicht zusammengeführt wurde und wir ihn trotzdem löschen wollen, würden Sie anstelle von -d -D verwenden.

Verwenden Sie als Nächstes den folgenden Befehl, um den Remote-Zweig auf GitHub zu löschen:

$ git push origin -d better-project-manager

Sie können den Remote-Zweig auch aus dem GitHub PR selbst löschen. Nach dem Zusammenführen oder Schließen sollte eine Schaltfläche angezeigt werden.