GitHub Pull-Anforderung zeigt Commits, die bereits im Zielsegment-Zweig vorhanden sind

Question

Ich versuche, ein Pull-Request auf GitHub zu einem Branch zu überprüfen, der nicht master ist. Der Zielbranch hinkte master hinterher und der Pull-Request zeigte Commits von master, also habe ich master gemerged und es auf GitHub gepusht, aber die Commits und die Änderungen für sie erscheinen immer noch im Pull-Request nach dem Aktualisieren. Ich habe mehrmals überprüft, dass der Branch auf GitHub die Commits von master hat. Warum erscheinen sie immer noch im Pull-Request?

Ich habe auch den Pull-Request lokal überprüft und es zeigt nur die nicht gemergten Commits.

Answer 1

Hier ist ein guter Workaround. Verwenden Sie die Bearbeiten-Schaltfläche, wenn Sie den PR in GitHub anzeigen, um den Basis-Zweig auf etwas anderes als master zu ändern. Wechseln Sie dann zurück zu master, und es werden nur die Änderungen aus den neuesten Commits korrekt angezeigt.

Answer 2

Es sieht so aus, als ob der Pull Request keine Änderungen am Zielbranch verfolgt (Ich habe den GitHub-Support kontaktiert und am 18. Nov 2014 die Antwort erhalten, dass dies so beabsichtigt ist).

Sie können jedoch die aktualisierten Änderungen anzeigen lassen, indem Sie folgendes tun:

http://githuburl/org/repo/compare/targetbranch...currentbranch

Ersetzen Sie githuburl, org, repo, targetbranch und currentbranch nach Bedarf.

Oder wie hexsprite in seiner Antwort darauf hingewiesen hat, können Sie es auch erzwingen, indem Sie auf Bearbeiten im PR klicken und das Basis-Ziel vorübergehend auf einen anderen Branch ändern und wieder zurücksetzen. Dies führt zu der Warnung:

Sind Sie sicher, dass Sie die Basis ändern möchten?

Einige Commits aus dem alten Basis-Branch können aus der Timeline entfernt werden und alte Überprüfungskommentare können veraltet werden.

Und es werden zwei Protokolleinträge im PR hinterlassen:

Answer 3

Zusammenfassend: GitHub rebase das Commit-Verlauf nicht automatisch in Pull-Requests. Die einfachsten Lösungen sind:

Lösung 1: Rebase

Angenommen, Sie möchten von feature-01 in master zusammenführen:

git fetch origin
git checkout feature-01
git rebase origin/master
git push --force-with-lease

Wenn Sie an einem Fork arbeiten, müssen Sie möglicherweise origin oben durch upstream ersetzen. Sehen Sie Wie aktualisiere ich einen GitHub geforkten Repository? um mehr über das Verfolgen von Remote-Branches des Original-Repositorys zu erfahren.

Lösung 2: Erstellen Sie einen neuen Pull-Request

Angenommen, Sie möchten von feature-01 in master zusammenführen:

git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased

Öffnen Sie nun einen Pull-Request für feature-01-rebased und schließen Sie den für feature-01.

Answer 4

Dies tritt bei GitHub auf, wenn Sie Commits zusammenführen, die aus dem Zielbranch übernommen wurden.

Ich hatte Squash und Merge mit GitHub als Standard-Merge-Strategie verwendet, einschließlich Merges aus dem Zielbranch. Dadurch wird ein neuer Commit eingeführt, und GitHub erkennt nicht, dass dieser zusammengeführte Commit derselbe ist wie diejenigen bereits im Master (jedoch mit unterschiedlichen Hashes). Git behandelt es richtig, aber Sie sehen alle Änderungen erneut in GitHub, was die Überprüfung nervig macht. Die Lösung besteht darin, eine normale Zusammenführung dieser von stromaufwärts gezogenen Commits durchzuführen, anstelle eines Squash und Merge. Wenn Sie einen anderen Branch in Ihren als Abhängigkeit zusammenführen möchten, git merge --squash und widerrufen Sie diesen einzelnen Commit, bevor Sie ihn aus dem Master ziehen, sobald dieser andere Branch tatsächlich im Master angekommen ist.

EDIT: Eine weitere Lösung besteht darin, zu rebasen und mit Gewalt zu drücken. Saubere, aber neu geschriebene Geschichte

Answer 5

Für alle anderen, die auf dieses Problem stoßen und von dem Verhalten von GitHub Pull Requests verwirrt sind, ist die Ursache, dass ein PR ein Unterschied zwischen dem Quellbranch-Ende und dem gemeinsamen Vorfahren des Quell- und Zielfilialen ist. Es zeigt daher alle Änderungen auf dem Quellbranch bis zum gemeinsamen Vorfahren und berücksichtigt keine Änderungen, die auf dem Zielfilialen aufgetreten sein könnten.

Weitere Informationen sind hier verfügbar: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

Diffs basierend auf einem gemeinsamen Vorfahren scheinen gefährlich zu sein. Ich wünschte, GitHub hätte die Möglichkeit, einen mehr standardmäßigen 3-Wege-Merge-basierten PR zu erstellen.

BEARBEITEN - Ich habe nie die offensichtliche Lösung erwähnt, die ich immer verwende, um mögliche Probleme zu vermeiden, die sich daraus ergeben könnten. Führen Sie einfach regelmäßig einen Merge Ihres Zielfilialen in Ihren PR-Branch durch, und Sie werden keine unangenehmen Überraschungen erleben.