Bevorzugter Github-Workflow für die Aktualisierung einer Pull-Anfrage nach der Code-Überprüfung

Question

Ich habe eine Änderung an einem Open-Source-Projekt auf Github eingereicht und Kommentare zur Codeüberprüfung von einem Mitglied des Kernteams erhalten.

Ich möchte den Code unter Berücksichtigung der Überprüfungskommentare aktualisieren und ihn erneut einreichen. Wie lässt sich dies am besten bewerkstelligen? Nach meinen begrenzten Kenntnissen über Git/Github könnte ich eine der folgenden Möglichkeiten nutzen:

1. Aktualisieren Sie den Code als neuen Commit und fügen Sie sowohl den ursprünglichen als auch den aktualisierten Commit zu meiner Pull-Anfrage hinzu.

2. Irgendwie (??) den alten Commit aus meinem Repository zurücksetzen und einen einzigen neuen Commit erstellen, der alles enthält, und dann eine Pull-Anfrage für diesen erstellen?

3. git commit hat eine Änderungsfunktion, aber ich habe gehört, dass man sie nicht mehr verwenden sollte, nachdem man den Commit außerhalb des lokalen Repositorys verschoben hat? In diesem Fall habe ich die Änderung auf meinem lokalen PC vorgenommen und in meinen Github-Zweig des Projekts verschoben. Wäre es in Ordnung, 'amend' zu verwenden?

4. Etwas anderes?

Es scheint, dass Option 2/3 gut wäre, da das Open-Source-Projekt nur einen Commit in seiner Geschichte hätte, der alles implementieren würde, aber ich bin nicht sicher, wie man das macht.

Hinweis: Ich weiß nicht, ob dies die Antwort beeinflusst oder nicht, aber ich habe die Änderungen nicht in einem separaten Zweig vorgenommen, sondern nur eine Übergabe an den Master gemacht

Answer 1

Um eine Pull-Anfrage zu aktualisieren

Um eine Pull-Anfrage zu aktualisieren (Punkt 1), müssen Sie nur denselben Zweig, aus dem die Pull-Anfrage stammt, auschecken und erneut pushen:

cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git push

Optional - Bereinigung des Übergabeprotokolls

Es kann sein, dass Sie gebeten werden, Ihre Commits zusammenzuquetschen, damit die Repository-Historie sauber ist, oder dass Sie selbst Zwischen-Commits entfernen wollen, die von der "Nachricht" in Ihrem Pull-Request ablenken (Punkt #2). Wenn Ihr Commit-Verlauf zum Beispiel so aussieht:

$ git remote add parent git@github.com:other-user/project.git
$ git fetch parent
$ git log --oneline parent/master..master
e4e32b8 add test case as per PR comments
eccaa56 code standard fixes as per PR comments
fb30112 correct typos and fatal error
58ae094 fixing problem

Es ist eine gute Idee, Dinge zusammenzufassen, damit sie als eine einzige Übertragung erscheinen:

$ git rebase -i parent/master 

Daraufhin werden Sie aufgefordert zu wählen, wie die Geschichte Ihres Pull-Requests umgeschrieben werden soll, das Folgende wird in Ihrem Editor erscheinen:

pick 58ae094 fixing actual problem
pick fb30112 correct typos
pick eccaa56 code standard fixes
pick e4e32b8 add test case as per PR comments

Für jeden Commit, der Teil des vorherigen Commits sein soll, ändern Sie pick in squash:

pick 58ae094 fixing actual problem
squash fb30112 correct typos
squash eccaa56 code standard fixes
squash e4e32b8 add test case as per PR comments

Und schließen Sie Ihren Editor. Git wird dann die Historie neu schreiben und Sie auffordern, eine Commit-Nachricht für den einen kombinierten Commit anzugeben. Ändern Sie diese entsprechend und Ihr Commit-Verlauf ist nun übersichtlich:

$ git log --oneline parent/master..master
9de3202 fixing actual problem

Schieben Sie das zu Ihrer Gabel:

$ git push -f
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 978 bytes, done.
Total 11 (delta 9), reused 7 (delta 6)
To git@github.com:me/my-fork.git
   f1238d0..9de3202  HEAD -> master

und Ihre Pull-Anfrage wird einen einzigen Commit enthalten, der alle Änderungen enthält, die zuvor in mehrere Commits aufgeteilt wurden.

Das Ändern der Historie in öffentlichen Repos ist eine schlechte Sache

Geschichte umschreiben und nutzen git push -f auf einem Zweig, den möglicherweise schon jemand anderes geklont hat, ist eine schlechte Sache - es führt dazu, dass die Geschichte des Repositorys und die des Checkouts auseinanderlaufen.

Wenn Sie jedoch die Historie Ihrer Abspaltung ändern, um die Änderung zu korrigieren, die Sie vorschlagen in ein Repository zu integrieren - ist eine gute Sache. Daher haben Sie keine Bedenken, "Lärm" aus Ihren Pull Requests herauszuquetschen.

Ein Hinweis zu Zweigniederlassungen

Oben zeige ich, dass die Pull-Anfrage von der master Zweig Ihres Forks zu veröffentlichen, ist nicht unbedingt falsch, aber es führt zu gewissen Einschränkungen, wie z.B., wenn dies Ihre Standardtechnik ist, dass Sie nur einen PR pro Repository offen haben können. Es ist jedoch besser, für jede einzelne Änderung, die Sie vorschlagen wollen, einen eigenen Zweig zu erstellen:

$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git push
# Now create PR from feature/new-widgets

Answer 2

Fügen Sie einfach einen neuen Commit zu dem in der Pull-Anfrage verwendeten Zweig hinzu und pushen Sie den Zweig auf GitHub. Die Pull-Anfrage wird automatisch mit dem zusätzlichen Commit aktualisiert.

Nr. 2 und Nr. 3 sind unnötig. Wenn die Leute nur sehen wollen, wo Ihr Zweig eingefügt wurde (und nicht die zusätzlichen Commits), können sie git log --first-parent um nur den Merge-Commit im Protokoll anzuzeigen.