Einführung
Der Beitrag zu Open-Source-Projekten ist eine lohnende Erfahrung, wenn Sie daran arbeiten, die Software für Endbenutzer wie Sie zu verbessern. Sobald Sie eine Pull-Anfrage eingereicht haben, muss der Code für den Beitrag zu einem Projekt möglicherweise vor der Akzeptanz umbasiert und überarbeitet werden, gefolgt von einer allgemeinen Bereinigung Ihrer Zweige.
Dieses Tutorial führt Sie durch einige der nächsten Schritte, die Sie möglicherweise ausführen müssen, nachdem Sie einpull request an ein Open-Source-Softwareprojekt gesendet haben.
Voraussetzungen
Dieses Tutorial führt Sie durch die Schritte, die Sie nach dem Erstellen einer Pull-Anfrage ausführen müssen. Sie sollten also Git bereits installiert haben und eine Pull-Anfrage erstellt haben oder darüber nachdenken.
Um mehr über den Beitrag zu Open Source-Projekten zu erfahren, lesen Siethis introduction. Informationen zum Erstellen von Pull-Anforderungen finden Sie unter "https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github[How To Create a Pull Request on GitHub". . "
Während Sie zu Open Source beitragen, stellen Sie möglicherweise fest, dass Konflikte zwischen Ihrer Verzweigungs- oder Pull-Anforderung und dem Upstream-Code bestehen. Möglicherweise wird in Ihrer Shell ein Fehler wie der folgende angezeigt:
OutputCONFLICT (content): Merge conflict in your-file.py
Automatic merge failed; fix conflicts and then commit the result.Oder wie folgt auf Ihrer Pull-Anfrage über die GitHub-Website:
Dies kann vorkommen, wenn die Betreuer eine Weile nicht auf Ihre Pull-Anfrage reagieren oder wenn viele Personen gleichzeitig einen Beitrag zum Projekt leisten. Wenn dies passiert und Sie Ihre Pull-Anfrage dennoch zusammenführen möchten, müssen Sie Konflikte lösen und Ihren Code neu erstellen.
Mitrebase können wir Zweige verschieben, indem wir das Commit ändern, auf dem sie basieren. Auf diese Weise können wir unseren Code neu strukturieren, um sie basierend auf den neueren Commits des Master-Zweigs zu erstellen. Das Zurücksetzen sollte mit Vorsicht erfolgen und Sie sollten sicherstellen, dass Sie während des gesamten Prozesses mit den richtigen Commits und auf dem richtigen Zweig arbeiten. Wir werden auch den Befehlgit reflogbelow verwenden, falls Sie einen Fehler machen.
Wie inpull request tutorial werden wir in das Codeverzeichnis wechseln und die neueste Upstream-Version des Codes abrufen.
cd repository
git fetch upstreamSobald Sie die vorgelagerte Version des Projekts abgerufen haben, können Sie Ihre Kommentare bereinigen, indem Sie Ihre Commit-Nachrichten entweder quetschen oder neu formulieren, um sie für die Projektbetreuer leichter verdaulich zu machen. Wenn Sie nicht viele kleine Commits durchgeführt haben, ist dies möglicherweise nicht erforderlich.
Um diesen Vorgang zu starten, führen Sie eine interaktive Rebase durch. Eininteractive rebase kann verwendet werden, um vorherige Festschreibungsnachrichten zu bearbeiten, mehrere Festschreibungen zu einer zusammenzufassen oder nicht mehr erforderliche Festschreibungen zu löschen oder zurückzusetzen. Dazu müssen wir in der Lage sein, die von uns getätigten Commits entweder nach Nummer oder nach einer Zeichenfolge zu referenzieren, die auf die Basis unseres Zweigs verweist.
Um herauszufinden, wie viele Commits wir ausgeführt haben, können wir die Gesamtzahl der Commits, die für das Projekt ausgeführt wurden, mit dem folgenden Befehl überprüfen:
git logSo erhalten Sie eine Ausgabe, die ungefähr so aussieht:
Outputcommit 46f196203a16b448bf86e0473246eda1d46d1273
Author: username-2
Date: Mon Dec 14 07:32:45 2015 -0400
Commit details
commit 66e506853b0366c87f4834bb6b39d941cd034fe3
Author: username1
Date: Fri Nov 27 20:24:45 2015 -0500
Commit details Das Protokoll zeigt alle im Repository des jeweiligen Projekts getätigten Commits an, sodass Ihre Commits mit den Commits anderer Projekte gemischt werden. Bei Projekten mit einem umfangreichen Commit-Verlauf mehrerer Autoren möchten Sie sich im Befehl als Autor angeben:
git log --author=your-usernameWenn Sie diesen Parameter angeben, sollten Sie in der Lage sein, die von Ihnen getätigten Commits zu zählen. Wenn Sie an mehreren Zweigen arbeiten, können Sie am Ende Ihres Befehls--branches[=<branch>] hinzufügen, um die Anzahl nach Zweigen zu begrenzen.
Wenn Sie nun die Anzahl der Commits kennen, die Sie für den Zweig vorgenommen haben, den Sie neu aufbauen möchten, können Sie den Befehlgit rebaseeinfach folgendermaßen ausführen:
git rebase -i HEAD~xHier bezieht sich-i auf die interaktive Rebase undHEAD auf das letzte Commit aus dem Hauptzweig. Diex sind die Anzahl der Commits, die Sie in Ihrem Zweig vorgenommen haben, seit Sie ihn zum ersten Mal abgerufen haben.
Wenn Sie jedoch nicht wissen, wie viele Commits Sie in Ihrem Zweig ausgeführt haben, müssen Sie ermitteln, welches Commit die Basis Ihres Zweigs ist. Führen Sie dazu den folgenden Befehl aus:
git merge-base new-branch masterDieser Befehl gibt eine lange Zeichenfolge zurück, die als Commit-Hash bezeichnet wird.
Output66e506853b0366c87f4834bb6b39d341cd094fe9Wir werden diesen Commit-Hash verwenden, um an den Befehlgit rebasezu übergeben:
git rebase -i 66e506853b0366c87f4834bb6b39d341cd094fe9Für jeden der obigen Befehle wird Ihr Befehlszeilentexteditor mit einer Datei geöffnet, die eine Liste aller Commits in Ihrem Zweig enthält, und Sie können jetzt wählen, ob Sie Commits quetschen oder neu formulieren möchten.
Squash-Commits
Wenn wir Commit-Nachrichten quetschen, quetschen oder kombinieren wir mehrere kleinere Commits zu einem größeren.
Vor jedem Commit wird das Wort "pick" angezeigt, sodass Ihre Datei bei zwei Commits ungefähr so aussieht:
GNU nano 2.0.6 File:… Benutzername / Repository / .git / rebase-merge / git-rebase-todo
pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature
# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))Jetzt sollten Sie für jede Zeile der Datei mit Ausnahme der ersten Zeile das Wort "pick" durch das Wort "squash" ersetzen, um die Festschreibungen zu kombinieren:
GNU nano 2.0.6 File:… Benutzername / Repository / .git / rebase-merge / git-rebase-todo
pick a1f29a6 Adding a new feature
squash 79c0e80 Here is another new featureZu diesem Zeitpunkt können Sie die Datei speichern und schließen. Dadurch wird eine neue Datei geöffnet, in der alle Festschreibungsnachrichten aller Festschreibungen zusammengefasst sind. Sie können die Festschreibungsnachricht nach Belieben umformulieren und die Datei dann speichern und schließen.
Sie erhalten Feedback, sobald Sie die Datei geschlossen haben:
OutputSuccessfully rebased and updated refs/heads/new-branch.Sie haben jetzt alle Festschreibungen zu einer zusammengefasst, indem Sie sie zusammengedrückt haben.
Reword Commits
Das Umschreiben von Commit-Nachrichten ist ideal, wenn Sie einen Tippfehler bemerken oder feststellen, dass Sie nicht für jedes Commit die parallele Sprache verwenden.
Sobald Sie die interaktive Rebase wie oben beschrieben mit dem Befehlgit rebase -i ausgeführt haben, wird eine Datei geöffnet, die folgendermaßen aussieht:
GNU nano 2.0.6 File:… Benutzername / Repository / .git / rebase-merge / git-rebase-todo
pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature
# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))Ersetzen Sie nun für jeden Commit, den Sie umformulieren möchten, das Wort "pick" durch "reword":
GNU nano 2.0.6 File:… Benutzername / Repository / .git / rebase-merge / git-rebase-todo
pick a1f29a6 Adding a new feature
reword 79c0e80 Adding a second new feature
# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))Sobald Sie die Datei gespeichert und geschlossen haben, wird in Ihrem Terminal-Editor eine neue Textdatei mit dem geänderten Wortlaut der Festschreibungsmeldung angezeigt. Wenn Sie die Datei erneut bearbeiten möchten, können Sie dies tun, bevor Sie die Datei speichern und schließen. Auf diese Weise können Sie sicherstellen, dass Ihre Commit-Nachrichten nützlich und einheitlich sind.
Schließen Sie den Neustart ab
Sobald Sie mit der Anzahl der ausgeführten Commits und den entsprechenden Commit-Meldungen zufrieden sind, sollten Sie den Rebase Ihrer Filiale über der neuesten Version des Upstream-Codes des Projekts abschließen. Führen Sie dazu den folgenden Befehl aus dem Verzeichnis Ihres Repositorys aus:
git rebase upstream/masterZu diesem Zeitpunkt beginnt Git, Ihre Commits auf der neuesten Version von master abzuspielen. Wenn dabei Konflikte auftreten, hält Git an, um Sie aufzufordern, Konflikte zu lösen, bevor Sie fortfahren.
Sobald Sie die Konflikte behoben haben, führen Sie Folgendes aus:
git rebase --continueDieser Befehl zeigt Git an, dass die Wiedergabe Ihrer Commits jetzt fortgesetzt werden kann.
Wenn Sie zuvor Commits mit dem Befehlsquashkombiniert haben, müssen Sie Konflikte nur einmal lösen.
Pull Request mit Force-Push aktualisieren
Sobald Sie eine Rebase durchführen, ändert sich der Verlauf Ihres Zweigs und Sie können den Befehlgit pushnicht mehr verwenden, da der direkte Pfad geändert wurde.
Wir müssen stattdessen das Flag--force oder-f verwenden, um die Änderungen zu erzwingen und Git darüber zu informieren, dass Sie genau wissen, was Sie verschieben.
Stellen wir zunächst sicher, dasspush.defaultsimple ist, was in Git 2.0+ die Standardeinstellung ist, indem wir es konfigurieren:
git config --global push.default simpleZu diesem Zeitpunkt sollten wir sicherstellen, dass wir uns auf dem richtigen Zweig befinden, indem wir uns den Zweig ansehen, an dem wir arbeiten:
git checkout new-branchOutputAlready on 'new-branch'
. . .Jetzt können wir den Force-Push ausführen:
git push -fJetzt sollten Sie Feedback zu Ihren Updates zusammen mit der Meldung erhalten, dass dies einforced update war. Ihre Pull-Anfrage ist jetzt aktualisiert.
Verlorene Commits wiederherstellen
Wenn Sie irgendwann ein Commit verworfen haben, das Sie wirklich in das größere Projekt integrieren wollten, sollten Sie in der Lage sein, mithilfe von Git Commits wiederherzustellen, die Sie möglicherweise versehentlich verworfen haben.
Wir werden den Befehlgit reflogverwenden, um unsere fehlenden Commits zu finden und dann einen neuen Zweig aus diesem Commit zu erstellen.
Reflog ist die Abkürzung fürreference logs, die aufzeichnet, wann die Tipps von Zweigen und anderen Referenzen zuletzt im lokalen Repository aktualisiert wurden.
Aus dem lokalen Verzeichnis des Code-Repository, in dem wir arbeiten, führen wir den folgenden Befehl aus:
git reflogSobald Sie diesen Befehl ausführen, erhalten Sie eine Ausgabe, die ungefähr so aussieht:
Output46f1962 HEAD@{0}: checkout: moving from branch-1 to new-branch
9370d03 HEAD@{1}: commit: code cleanups
a1f29a6 HEAD@{2}: commit: brand new feature
38f2fc2 HEAD@{3}: commit: remove testing methods
. . .In Ihren Festschreibungsnachrichten erfahren Sie, welche der Festschreibungen diejenige ist, die Sie zurückgelassen haben, und die entsprechende Zeichenfolge befindet sich vor denHEAD@{x}-Informationen auf der linken Seite Ihres Terminalfensters.
Jetzt können Sie diese Informationen übernehmen und einen neuen Zweig aus dem entsprechenden Commit erstellen:
git checkout -b new-new-branch a1f29a6Im obigen Beispiel haben wir aus dem oben gezeigten dritten Commit einen neuen Zweig erstellt, der ein "brandneues Feature" eingeführt hat, das durch die Zeichenfolgea1f29a6 dargestellt wird.
Je nachdem, was Sie von hier aus tun müssen, können Sie die Schritte zum Einrichten Ihres Zweigs inthis tutorial on pull requests ausführen oder zutop of the current tutorial zurückkehren, um die Neubasierung des neuen Zweigs durchzuführen.
[.note] #Note: Wenn Sie kürzlich den Befehlgit gc ausgeführt haben, um unnötige Dateien zu bereinigen und das lokale Repository zu optimieren, können Sie verlorene Commits möglicherweise nicht wiederherstellen.
#
Was bei einer Codeüberprüfung zu erwarten ist
Wenn Sie eine Pull-Anfrage einreichen, befinden Sie sich im Dialog mit einem größeren Projekt. Wenn Sie eine Pull-Anfrage einreichen, werden andere eingeladen, über Ihre Arbeit zu sprechen, so wie Sie selbst über ein größeres Projekt sprechen und sich mit ihm befassen. Für ein erfolgreiches Gespräch ist es wichtig, dass Siewhy, über die Sie die Pull-Anforderung stellen, über Ihre Commit-Nachrichten kommunizieren können. Daher ist es am besten, so präzise und klar wie möglich zu sein.
Die Überprüfung der Pull-Anforderung kann je nach Projekt langwierig und detailliert sein. Es ist am besten, sich den Prozess als eine Lernerfahrung vorzustellen und eine gute Möglichkeit für Sie, Ihren Code zu verbessern und die Abrufanforderung besser und besser auf die Anforderungen des Softwareprojekts abzustimmen. Die Überprüfung sollte es Ihnen ermöglichen, die Änderungen selbst anhand der Empfehlungen und Anweisungen des Betreuers vorzunehmen.
Die Pull-Anforderung führt ein Protokoll mit Notizen von Überprüfern sowie allen Aktualisierungen und Diskussionen, die Sie zusammen haben. Möglicherweise müssen Sie während dieses Vorgangs mehrere zusätzliche Festschreibungen vornehmen, bevor die Pull-Anforderung akzeptiert wird. Dies ist völlig normal und bietet eine gute Gelegenheit, als Teil eines Teams an der Überarbeitung zu arbeiten.
Ihre Pull-Anforderung wird weiterhin über Git verwaltet und während des gesamten Vorgangs automatisch aktualisiert, solange Sie dem gleichen Zweig weitere Commits hinzufügen und diese an Ihre Abzweigung senden.
Obwohl Sie Ihren Code zur Überprüfung durch Ihre Kollegen in die größere Welt stellen, sollten Sie niemals das Gefühl haben, dass die Überprüfung persönlich wird. Lesen Sie daher unbedingt die relevantenCONTRIBUTION.md-Dateien oder Verhaltenskodizes. Es ist wichtig sicherzustellen, dass Ihre Verpflichtungen mit den im Projekt festgelegten Richtlinien übereinstimmen. Wenn Sie sich jedoch unwohl fühlen, verdient das Projekt, an dem Sie arbeiten, möglicherweise nicht Ihren Beitrag. Es gibt viele einladende Bereiche in der Open-Source-Community, und obwohl Sie davon ausgehen können, dass Ihr Code kritisch betrachtet wird, sollten Sie professionelles und höfliches Feedback erhalten.
Pull Request Acceptance und Löschen Ihrer Filiale
Herzliche Glückwünsche! Wenn Ihre Pull-Anfrage angenommen wurde, haben Sie erfolgreich einen Beitrag für ein Open-Source-Softwareprojekt geleistet!
Zu diesem Zeitpunkt müssen Sie die Änderungen, die Sie vorgenommen haben, über Ihr lokales Repository zurück in Ihre Abzweigung ziehen. Dies haben Sie bereits getan, als Sie den Prozess zusync your fork durchlaufen haben. Sie können dies mit den folgenden Befehlen in Ihrem Terminalfenster tun:
git checkout master
git pull --rebase upstream master
git push -f origin masterJetzt sollten Sie sowohl Ihre lokalen als auch Ihre Remote-Zweige bereinigen, indem Sie den Zweig entfernen, den Sie an beiden Stellen erstellt haben, da sie nicht mehr benötigt werden. Entfernen wir zunächst den lokalen Zweig:
git branch -d new-branchDas dem Befehlgit branch hinzugefügte Flag-d löscht den Zweig, den Sie an den Befehl übergeben. Im obigen Beispiel heißt esnew-branch.
Als Nächstes entfernen wir den Remote-Zweig:
git push origin --delete new-branchMit den gelöschten Zweigen haben Sie das Repository aufgeräumt und Ihre Änderungen befinden sich jetzt im Hauptrepository. Sie sollten bedenken, dass die Änderungen, die Sie über Ihre Pull-Anforderung vorgenommen haben, jetzt Teil des Haupt-Repositorys sind und möglicherweise nicht für den durchschnittlichen Endbenutzer verfügbar sind, der öffentliche Versionen herunterlädt. Generell werden Software-Betreuer mehrere neue Funktionen und Fehlerbehebungen in einer einzigen öffentlichen Version zusammenfassen.
Fazit
Dieses Tutorial führte Sie durch einige der nächsten Schritte, die Sie möglicherweise ausführen müssen, nachdem Sie einpull request an ein Open-Source-Software-Repository gesendet haben.
Zu Open-Source-Projekten beizutragen - und ein aktiver Open-Source-Entwickler zu werden - ist oft eine lohnende Erfahrung. Durch regelmäßige Beiträge zu häufig verwendeter Software wird sichergestellt, dass diese für die Benutzergemeinschaft wertvoll und nützlich ist.