Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Workflow eines Pull Requests

Der so genannte "PR-Workflow", der von Godot verwendet wird, ist bei vielen Projekten, die Git verwenden, üblich und sollte erfahrenen Mitwirkenden an freier Software bekannt sein. Die Idee ist, dass nur eine kleine Anzahl von Personen (wenn überhaupt welche) direkt in den master-Branch einchecken. Stattdessen forken die Mitwirkenden das Projekt (d.h. sie erstellen eine Kopie davon, die sie nach Belieben verändern können), und verwenden dann die GitHub-Benutzeroberfläche, um einen Pull von einem der Branches ihres Forks in einen Branch des ursprünglichen (oft upstream genannten) Repositorys zu beantragen.

Der daraus resultierende Pull Request (PR) kann dann von anderen Mitwirkenden geprüft werden, die ihn genehmigen oder ablehnen können, oder meistens Änderungen verlangen. Sobald der PR genehmigt ist, kann er von einem der Kernentwickler gemergt werden, und seine Commits werden Teil des Ziel-Branchs (üblicherweise der master-Branch).

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

Git Quellcode-Repository

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

Bemerkung

Wenn Sie einen Beitrag zur Dokumentation leisten möchten, finden Sie das Repository hier.

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-Kommandozeile 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-Workflow 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 einem Peer-Review).

Siehe auch

Die ersten Abschnitte des Git-"Buchs" sind eine gute Einführung in die Philosophie des Tools und die verschiedenen Befehle, die Sie in Ihrem täglichen Arbeitsablauf beherrschen müssen. Sie können sie online auf der Website von Git SCM lesen. Sie können auch die interaktiven Anleitung von GitHub ausprobieren.

Die Branches im Git-Repository sind wie folgt organisiert:

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

• Die stable Branches sind nach ihrer Version benannt, z.B. 3.1 und 2.1. Sie werden verwendet, um Bugfixes und Verbesserungen aus dem master-Branch in die aktuell gepflegte stable Version (z.B. 3.1.2 oder 2.1.6) zurückzuportieren. Als Faustregel gilt, dass der letzte stable Branch bis zur nächsten Minor-Version gepflegt wird (z.B. wurde der 3.0-Branch bis zur Veröffentlichung von Godot 3.1 gepflegt). Wenn Sie PRs gegen einen gepflegten stable Branch machen wollen, prüfen Sie bitte zuerst, ob Ihre Änderungen auch für den master-Branch relevant sind, und wenn ja, geben Sie dem PR für den master-Branch höhere Priorität. Die Release-Manager können dann die Korrektur für einen stable Branch cherry-picken, wenn dies relevant ist.

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

Forking und Cloning

Der erste Schritt besteht darin, das godotengine/godot repository auf GitHub zu forken. Dazu benötigen Sie ein GitHub-Konto und müssen angemeldet sein. In der oberen rechten Ecke der GitHub-Seite des Repositorys sollten Sie den "Fork"-Button wie unten gezeigt sehen:

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

Sie können dann Ihren Fork klonen, d.h. eine lokale Kopie des Online-Repositorys erstellen (in Git-Sprache den Origin Remote). Wenn Sie dies noch nicht getan haben, laden Sie Git von der Website 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 geforkt 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 master-Branch ziehen möchten, um Ihren Fork zu aktualisieren. Sie haben eine weitere Remote-Referenz namens origin, die auf Ihren Fork zeigt (USERNAME/godot).

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

Bemerkung

Branch it, pull it, code it, stage it, commit, push it, rebase it... technologic.

Diese schlechte Interpretation von Daft Punks Technologic zeigt die allgemeine Vorstellung, die Git-Anfänger von seinem Workflow haben: viele seltsame Befehle, die man durch Kopieren und Einfügen lernen muss, in der Hoffnung, dass sie wie erwartet funktionieren werden. Und das ist eigentlich keine schlechte Art zu lernen, solange man neugierig ist und nicht zögert, seine Suchmaschine zu befragen, wenn man sich verirrt hat, also geben wir Ihnen die grundlegenden Befehle, die man bei der Arbeit mit Git kennen sollte.

Im Folgenden nehmen wir als Beispiel an, dass Sie ein Feature in Godots Projektmanager implementieren wollen, die in der Datei editor/project_manager.cpp programmiert ist.

Branches erzeugen

Standardmäßig sollte git clone Sie auf den master-Branch Ihres Forks (origin) gebracht haben. Um mit der Entwicklung Ihrer eigenen Features zu beginnen, werden wir einen Feature-Branch erstellen:

# 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 macht das gleiche wie oben:

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

Wenn Sie zum master-Branch zurückkehren möchten, verwenden Sie:

$ git checkout master

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

$ git branch
  2.1
* better-project-manager
  master

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

$ git checkout -b my-new-feature master

Ihren Branch 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-Branch Ihres Forks mehrere Commits hinter dem master-Branch des Upstreams liegt: Pull Requests von anderen Mitwirkenden wären in der Zwischenzeit gemergt worden.

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

$ git pull --rebase upstream master

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

Während des Rebasings können Konflikte auftreten, wenn Ihre Commits Code ändern, der in der Zwischenzeit im Upstream-Branch geändert worden ist. In diesem Fall hält Git bei dem Commit, der den Konflikt verursacht, an und fordert Sie auf, die Konflikte zu lö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 aufweisen, bis der Rebase-Vorgang 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 Branches, 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 Branches machen soll. Sollten Konflikte auftreten, würden sie durch diesen Merge-Commit auf einmal aufgelöst werden.

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

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 Mergen 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 Mergen 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-Branch zu anzuwenden. Siehe den entsprechenden Abschnitt für Hinweise.

Tipp

Wenn Sie zu irgendeinem Zeitpunkt einen lokalen Branch auf einen bestimmten Commit oder Branch 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 Branch 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 gestaged wird, während sie gestaged wird und nachdem sie commited wurde.

• git diff zeigt Ihnen die aktuellen nicht gestageten Änderungen an, d.h. die Unterschiede zwischen Ihrem Arbeitsverzeichnis und dem Staging-Bereich.

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

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

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

• git reset HEAD <files> nimmt das Stagen von Änderungen an den aufgelisteten Dateien zurück.

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

• git commit committet die gestageten Dateien. Öffnet einen Texteditor (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-Log schreiben können. Sie können git commit -m "Cooles Commit-Log" verwenden, um das Log 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 (Bugs, Tippfehler, Stilprobleme, etc.).

• git log zeigt Ihnen die letzten Commits Ihres aktuellen Branchs an. Wenn Sie lokale Commits vorgenommen haben, müssten diese ganz oben angezeigt werden.

• git show zeigt Ihnen die Änderungen des letzten Commits an. 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 prägen Sie es sich durch wiederholtes Anwenden ein.

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-Branch haben, die nicht im master-Branch waren. Sie sind aber immer noch nur lokal - der entfernte Fork kennt sie nicht, ebenso wenig wie das Upstream-Repository.

Änderungen auf einen Remote-Rechner pushen

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 Remote-Repository verändert). Sie müssen die neuen Commits in einen Remote-Branch pushen, um sie mit der Welt zu teilen. Die Syntax dafür ist:

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

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

$ git push origin better-project-manager

Git fragt Sie nach Ihrem Benutzernamen und Passwort. Geben Sie für Ihr Passwort Ihr GitHub Personal Access Token (PAT) ein. Wenn Sie kein GitHub Personal Access Token haben oder keins mit den richtigen Berechtigungen für Ihr neu geforktes Repository, müssen Sie eines erstellen. Folgen Sie diesem Link, um Ihr persönliches Zugriffstoken zu erstellen: Verwalten deiner persönlichen Zugriffstoken.

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

Einen Pull Request aufsetzen

Wenn Sie den Branch Ihres Forks auf GitHub laden, sollten Sie eine Zeile sehen, die sagt "This branch is 2 commits ahead of godotengine:master." (und möglicherweise einige Commits dahinter, wenn Ihr master-Branch nicht mit dem Upstream-Branch master synchronisiert war).

In dieser Zeile befindet sich ein "Pull request"-Link. Wenn Sie darauf klicken, öffnet sich ein Formular, mit dem Sie einen Pull Request für das godotengine/godot Upstream-Repository erstellen können. Es sollte Ihnen Ihre beiden Commits zeigen und "Able to merge" anzeigen. Wenn das nicht der Fall ist (z.B. weil es viel mehr Commits hat oder weil es Merge-Konflikte gibt), erstellen Sie den PR noch nicht, irgendetwas ist schief gelaufen. Gehen Sie zu unserem Godot-Mitwirkenden-Chat und bitten Sie um Unterstützung :)

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, um zu zeigen, was Ihr Beitrag beinhaltet. Klicken Sie auf "Create a pull request" und tadaa!

Einen Pull Request verändern

Während er von anderen Mitwirkenden gereviewt wird, müssen Sie häufig Änderungen an Ihrem noch nicht gemergten PR vornehmen, entweder weil die Mitwirkenden darum gebeten haben oder weil Sie beim Testen selbst Probleme festgestellt haben.

Die gute Nachricht ist, dass Sie einen Pull Request ändern können, indem Sie einfach auf dem Branch arbeiten, von dem aus Sie den Pull Request gestellt haben. Sie können z.B. einen neuen Commit für diesen Branch erstellen, ihn auf Ihren Fork pushen, und der 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

Seien Sie sich jedoch bewusst, dass wir in unserem PR-Workflow Commits bevorzugen, die unsere Codebasis von einem funktionalen Zustand in einen anderen funktionalen Zustand bringen, ohne dass es Zwischen-Commits gibt, die Bugs in Ihrem eigenen Code oder Stilprobleme beheben. In den meisten Fällen bevorzugen wir einen einzigen Commit in einem bestimmten PR (es sei denn, es gibt einen guten Grund, die Änderungen getrennt zu halten). Anstatt einen neuen Commit zu erstellen, sollten Sie git commit --amend verwenden, um den vorherigen Commit mit Ihren Korrekturen zu ergänzen. Das obige Beispiel würde dann so aussehen:

# 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

Das interaktive Rebase

If you didn't follow the above steps closely to amend changes into a commit instead of creating fixup commits, or if you authored your changes without being aware of our workflow and Git usage tips, reviewers might request you to rebase your branch to squash some or all of the commits into one.

Wenn nämlich einige Commits nach Reviews vorgenommen wurden, um Bugs, Tippfehler usw. im ursprünglichen Commit zu beheben, sind sie für einen zukünftigen Leser des Change-Log, der wissen möchte, was in der Godot-Codebasis geschehen ist, oder wann und wie eine bestimmte Datei zuletzt geändert wurde, nicht relevant.

Um diese fremden Commits in die Haupt-Commits zu vereinen, müssen wir die Geschichte umschreiben. Richtig, wir haben diese Macht. Sie haben vielleicht schonmal gelesen, dass es eine schlechte Praxis sei, und das stimmt auch, wenn es um Branches 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 Branch-Namen als Argument und lässt Sie alle Commits zwischen diesem Commit/Branch und dem letzten in Ihrem Arbeits-Branch, dem sogenannten HEAD, ändern.

Sie können zwar eine beliebige Commit-ID an git rebase -i übergeben und alles, was dazwischen liegt, reviewen, aber der gängigste und bequemste Workflow beinhaltet das Rebasen auf den Upstream-Branch master, was Sie wie folgt machen können:

$ git rebase -i upstream/master

Bemerkung

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

Interaktive Rebases können nur auf lokalen Branches durchgeführt werden, daher ist das / hier wichtig. Da sich der Upstream-Branch häufig ändert, kann Ihr lokaler upstream/master-Branch 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 Branch aktualisieren würde, wird fetch nur die upstream/master-Referenz aktualisieren (die sich von Ihrem lokalen master-Branch unterscheidet... ja, es ist verwirrend, aber Sie werden sich nach und nach daran gewöhnen).

Dies öffnet einen Texteditor (standardmäßig vi, siehe Git docs um Ihren Lieblingseditor zu konfigurieren) mit etwas, das so aussehen könnte:

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 tun), und dass "squash" und "fixup" verwendet werden können, um den Commit in seinen Parent-Commit zu verschmelzen. Der Unterschied zwischen "squash" und "fixup" ist, dass "fixup" das Commit-Log des gesquashten 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 Remote-Branch 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 Remote-Branch zu pushen, wird dies 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.

This is reasonable behavior, Git will not let you push changes that would override remote content. But that's actually what we want to do here, so we will have to force it:

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

Und tadaa! Git wird fröhlich den Remote-Branch 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 PRs entsprechend aktualisieren.

Rebasing onto another branch

If you have accidentally opened your PR on the wrong branch, or need to target another branch for some reason, you might need to filter out a lot of commits that differ between the old branch (for example 4.2) and the new branch (for example master). This can make rebasing difficult and tedious. Fortunately git has a command just for this situation, git rebase --onto.

If your PR was created from the 4.2 branch and you want to update it to instead start at master the following steps should fix this in one step:

$ git rebase -i --onto master 4.2

This will take all the commits on your branch after the 4.2 branch, and then splice them on top of master, ignoring any commits from the 4.2 branch not on the master branch. You may still need to do some fixing, but this command should save you a lot of tedious work removing commits.

Just like above for the interactive rebase you need to force push your branch to handle the different changes:

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

Löschen eines Git-Branchs

Nachdem Ihr Pull Request gemergt wurde, sollten Sie noch etwas tun: Löschen Sie Ihren Git-Branch für den PR. Es ist kein Problem, wenn Sie Ihren Branch nicht löschen, aber es wird empfohlen, dies zu tun. Sie müssen dies zweimal tun, einmal für den lokalen Branch und einmal für den Remote-Branch auf GitHub.

Um unseren better-project-manager-Branch lokal zu löschen, verwenden Sie diesen Befehl:

$ git branch -d better-project-manager

Wenn der Branch noch nicht gemergt wurde und wir ihn trotzdem löschen wollen, würden Sie -D statt -d verwenden.

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

$ git push origin -d better-project-manager

Sie können den Remote-Branch auch aus dem GitHub PR selbst löschen. Nach dem Mergen oder Schließen sollte dort ein Button angezeigt werden.