it-swarm.com.de

GitHub-Pull-Anforderung mit Commits, die sich bereits im Zielzweig befinden

Ich versuche, eine Pull-Anfrage auf GitHub an einen Zweig zu überprüfen, der kein Master ist. Der Zielzweig befand sich hinter master und die Pull-Anforderung zeigte Commits von master an. Daher habe ich master zusammengeführt und an GitHub übertragen, aber die Commits und Diffs für sie werden nach dem Aktualisieren weiterhin in der Pull-Anforderung angezeigt. Ich habe doppelt geprüft, ob der Zweig auf GitHub die Commits von master enthält. Warum erscheinen sie immer noch in der Pull-Anfrage?

Ich habe die Pull-Anfrage auch lokal ausgecheckt und sie zeigt nur die nicht zusammengeführten Commits an.

95
lobati

Es sieht so aus, als ob die Pull-Anforderung Änderungen am Zielzweig nicht nachverfolgt (Ich habe den GitHub-Support kontaktiert und am 18. November 2014 eine Antwort erhalten, die besagt, dass dies beabsichtigt ist).

Sie können sich jedoch die aktualisierten Änderungen anzeigen lassen, indem Sie wie folgt vorgehen:

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

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

Wie Hexsprite in seiner Antwort hervorhob, können Sie die Aktualisierung auch erzwingen, indem Sie auf klicken Edit auf der PR und vorübergehend die Basis zu einem anderen Zweig und wieder zurück zu ändern. Dies erzeugt die Warnung:

Möchten Sie die Basis wirklich ändern?

Einige Commits aus dem alten Basiszweig werden möglicherweise von der Zeitleiste entfernt, und alte Überprüfungskommentare sind möglicherweise veraltet.

Und wird lassen Sie zwei Protokolleinträge in der PR:

enter image description here

77
Adam Millerchip

Hier ist eine gute Lösung. Verwenden Sie die Schaltfläche Edit, wenn Sie die PR in GitHub anzeigen, um den Basiszweig in etwas anderes als master zu ändern. Wechseln Sie dann zurück zu master und es werden nur die Änderungen der letzten Commits korrekt angezeigt.

47
hexsprite

Zusammenfassend lässt sich sagen, dass GitHub den Commit-Verlauf in Pull-Anforderungen nicht automatisch neu erstellt. Die einfachsten Lösungen sind:

Lösung 1: Neu starten

Angenommen, Sie möchten aus feature-01 In master zusammenführen:

git fetch Origin
git checkout feature-01
git rebase Origin/master
git Push --force

Wenn Sie an einer Gabel arbeiten, müssen Sie möglicherweise Origin oben durch upstream ersetzen. In Wie aktualisiere ich ein GitHub-Forked-Repository? erfahren Sie mehr über das Verfolgen von Remotezweigen des ursprünglichen Repositorys.

Lösung 2: Erstellen Sie eine neue Pull-Anfrage

Angenommen, Sie möchten intro master aus feature-01 Zusammenführen:

git checkout feature-01
git checkout -b feature-01-rebased
git Push -u Origin feature-01-rebased

Öffnen Sie nun eine Pull-Anfrage für feature-01-rebased Und schließen Sie die für feature-01.

22

Eine Möglichkeit, dies zu beheben, besteht darin, git rebase targetbranch in dieser PR. Dann git Push --force targetbranch, dann zeigt Github die richtigen Commits und Diff. Seien Sie vorsichtig, wenn Sie nicht wissen, was Sie tun. Vielleicht checken Sie zuerst einen Testzweig aus, um den Rebase durchzuführen, dann git diff targetbranch um sicherzustellen, dass es immer noch das ist, was Sie wollen.

13
Elijah Lynn

Für alle anderen, die dies bemerken und durch das GitHub Pull Request-Verhalten verwirrt sind, ist die Hauptursache, dass ein PR ein Unterschied zwischen dem Quellzweig-Tipp und dem gemeinsamen Vorfahren des Quellzweigs und des Zielzweigs ist. Es werden daher alle Änderungen im Quellzweig bis zum gemeinsamen Vorgänger angezeigt, und Änderungen, die möglicherweise im Zielzweig aufgetreten sind, werden nicht berücksichtigt.

Weitere Informationen finden Sie hier: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

Auf gemeinsamen Vorfahren basierende Unterschiede scheinen gefährlich zu sein. Ich wünschte, GitHub hätte die Option, eine standardisierte 3-Wege-Merge-basierte PR zu erstellen.

8
David K. Hess

Sie müssen Ihrer ~/.gitconfig - Datei Folgendes hinzufügen:

[rebase]
    autosquash = true

Dies wird automatisch das Gleiche erreichen wie das, was diese Antwort zeigt.

Ich habe das von hier .

8
Elena

Dies passiert mit GitHub, wenn Sie Squash-Commits aus dem Zielzweig zusammenführen.

Ich hatte Squash and Merge mit Github als Standard-Mergestrategie verwendet, einschließlich Merges aus dem Zielzweig. Dies führt ein neues Commit ein und GitHub erkennt nicht, dass dieses gequetschte Commit dasselbe ist wie das, das bereits im Master vorhanden ist (jedoch mit unterschiedlichen Hashes). Git handhabt es richtig, aber Sie sehen alle Änderungen wieder in GitHub, was das Überprüfen nervt. Die Lösung besteht darin, diese eingezogenen Upstream-Commits regelmäßig anstelle eines Squash-and-Merge-Vorgangs zusammenzuführen. Wenn Sie einen anderen Zweig als Abhängigkeit in Ihren Zweig einfügen möchten, git merge --squash und setzen Sie diesen einzelnen Commit zurück, bevor Sie ihn vom Master abrufen, sobald der andere Zweig den Master erreicht hat.

3
achilleverheye

Ich bin mir nicht ganz sicher, welche Theorie dahinter steckt. Aber ich habe das mehrmals bekommen und kann das folgendermaßen beheben.

git pull --rebase

Dadurch werden die Änderungen aus Ihrem ursprünglichen Repo-Master-Zweig abgerufen und zusammengeführt (falls Sie darauf hingewiesen haben).

Dann pushen Sie Ihre Änderungen mit Nachdruck in Ihr Github-geklontes Repository (Ziel).

git Push -f Origin master

Dadurch stellen Sie sicher, dass Ihr Github-Klon und Ihr übergeordnetes Repo auf demselben Github-Commit-Level sind und Sie keine unnötigen Änderungen zwischen den Zweigen sehen.

0
Chanaka udaya