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

Ich bin darauf gestoßen, nachdem ich einen PR für eine Korrektur in einen anderen Entwicklungszweig erstellt hatte. Nachdem ich die Änderungen bemerkt hatte, die ich nicht im PR gemacht hatte, habe ich sowohl aus dem Hauptzweig als auch aus beiden Zweigen zusammengeführt. Das hat nicht geholfen. Aber die zusätzlichen Änderungen sind verschwunden, nachdem ich den Ziweig in meinen Zweig fusioniert habe.

git checkout 
git merge 
git commit -a
git push

Bevor ich dies getan habe, habe ich eine Kopie meines Quellzweigs gespeichert. Seine Commit-Historie zeigt nur eine der Zusammenführungen: Zweig 'main' in zusammenführen. Nach dem Zusammenführen wie oben, geht diesem in der Historie ein neuer Commit voraus Zweig 'main' in zusammenführen.

Der durch die Fusion aus dem Zielzweig eingeführte Commit (oben) zeigt keine Änderungen. Auch vor dem Zusammenführen zeigten die Unterschiede zwischen den Zweigen keine Änderungen, die im PR enthalten waren.

Vor der neuen Fusion aus dem Zielzweig scheint der PR nicht die Änderungen widerzuspiegeln, die nach dem Öffnen des PR im Zielzweig eingeführt wurden. Für mich hat das Fusionieren aus dem Zielzweig die Dinge auf den erwarteten Stand zurückgesetzt.

Answer 2

Geschichte zu meinem Problem, bevor ich antworte:

Ich werde 3 Zweige in Betracht ziehen, master, testing, feature.

Testing Zweig würde bereits Master Änderungen haben.

Das Problem entsteht für mich, wenn ich Master in meinen Feature Zweig zusammenführe, dann arbeite und committe in meinen Feature Zweig und wenn ich eine PR gegen Testing erstelle, zeigt es Änderungen, die bereits in Testing sind, erneut an. Das ist frustrierend und meine Kollegen haben dieses Problem nicht, weil sie das Eingabeaufforderungs nutzen. Und ich möchte nicht das Eingabeaufforderungs benutzen.

Ich benutze die GitHub Desktop App und das passiert mir häufig und ich konnte bis heute nichts dagegen tun.

Wenn Sie zählbare Commits haben (4-5 maximal) auf Ihrem Feature Zweig, dann ist dieses Verfahren nützlich. Sie könnten verwirrt sein, wenn es viele Commits gibt.

Jetzt die Workaround-Lösung für GitHub Desktop-Benutzer:

1. Erstellen Sie einen Zweig aus Testing und benennen Sie ihn "Feature-Merge-to-Testing".
2. Cherry-Pick diese Commits auf "Feature-Merge-to-Testing".
3. Konflikte lösen.
4. Erstellen Sie jetzt eine PR gegen den Testing Zweig.
5. Löschen Sie den "Feature-Merge-to-Testing" Zweig, wenn Sie fertig sind.

Bis GitHub das Problem mit PRs in der Desktop-Anwendung behebt. Ich denke, ich werde dieses Verfahren befolgen, das für mich zu funktionieren scheint. Lassen Sie mich wissen, ob es einen effektiveren Workaround gibt.

Und dass das Ändern der Basis (die erste Antwort auf diese Frage) für mich nicht funktioniert hat.

Answer 3

Ich habe eine Möglichkeit gefunden, das richtige Verhalten zu erhalten (getestet im November 2020).

Nach git merge und der Konfliktlösung muss stattdessen git merge --continue verwendet werden, anstelle von git commit ....

Answer 4

Fehlerfreier Ansatz, wenn Sie zu besorgt sind, Dinge durcheinander zu bringen: Gehen Sie zur Datei und entfernen Sie die Änderungen manuell, dann squashen Sie mit Ihrem letzten Commit mit

git add .  && git commit -a --allow-empty-message -m '' && git reset --soft HEAD~2 &&
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"

Wenn es keine Konflikte gibt, sind Sie bereit loszulegen!