Git rebase –continue beschwert sich, selbst wenn alle Merge-Konflikte gelöst wurden

Lesezeit: 9 Minuten

Benutzer-Avatar
Lukas

Ich stehe vor einem Problem, bei dem ich nicht sicher bin, wie ich es lösen soll.

Ich habe eine Rebase gegen Master aus meinem Zweig durchgeführt:

git rebase master

und bekam folgenden Fehler

 First, rewinding head to replay your work on top of it...
 Applying: checkstyled.
 Using index info to reconstruct a base tree...
 Falling back to patching base and 3-way merge...
 Auto-merging AssetsLoader.java
 CONFLICT (content): Merge conflict in AssetsLoader.java
 Failed to merge in the changes.
 Patch failed at 0001 checkstyled.

Also ging ich zu meinem Lieblingseditor, behob den 1-Zeilen-Konflikt, speicherte die Datei und machte einen Git-Status und bekam die folgende Ausgabe:

 # Not currently on any branch.
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #  modified:   PassengerContactHandler.java
 #
 # Unmerged paths:
 #   (use "git reset HEAD <file>..." to unstage)
 #   (use "git add/rm <file>..." as appropriate to mark resolution)
 #
 #  both modified:      AssetsLoader.java
 #

Ich habe einen Git AssetsLoader.java und einen Git-Status hinzugefügt und Folgendes erhalten:

 # Not currently on any branch.
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #  modified:   AssetsLoader.java
 #  modified:   PassengerContactHandler.java
 #

und als ich git rebase –continue gemacht habe, bekomme ich:

git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

Ich weiß, dass ich den Patch überspringen und die Rebase fortsetzen kann, aber ich bin mir nicht sicher, ob die Änderungen in PassengerContactHandler.java in meinen Zweig rebasiert werden oder nicht.

also bin ich mir nicht sicher, wie soll ich weiter vorgehen?

Edit: Könnte es sein, dass die Datei mit dem gelösten Konflikt genau wie die Originalversion ist?

Vielen Dank, Lukas

Edit, mir ist es gerade wieder passiert:

Es ist mir gerade wieder passiert,

(307ac0d...)|REBASE)$ git status
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   assets/world/level1/Level-1.xml
#   modified:   George.java
#   modified:   DefaultPassenger.java
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   mb-art/originalAssets/27dec/

((307ac0d…)|REBASE)$ git rebase –fortfahren

You must edit all merge conflicts and then
mark them as resolved using git add

git –version

git version 1.7.1

  • Das ist die volle Ausgabe von git status, Rechts? Kein fehlender Abschnitt darunter?

    – Kaskabel

    15. Dezember 2011 um 18:28 Uhr

  • git-rebase sollte niemals melden, dass es ungelöste Konflikte gibt, wenn es keine gibt. Wenn Sie es schaffen, das Problem in einem einfacheren Testfall zu reproduzieren, wäre es viel einfacher zu debuggen, aber immer noch, wenn Sie es haben git status meldet keine Konflikte wann git rebase --continue tut und Ihre Git-Version aktuell ist, können Sie versuchen, die Git-Entwickler-Mailingliste unter [email protected] mit so vielen Diagnoseinformationen wie möglich per E-Mail zu kontaktieren.

    – Kaskabel

    21. Dezember 2011 um 22:55 Uhr

  • Es ist mir gerade wieder passiert, (307ac0d…)|REBASE)$ git status # Momentan auf keinem Zweig. # Festzuschreibende Änderungen: # (verwenden Sie “git reset HEAD …”, um die Bereitstellung aufzuheben) # # geändert: assets/world/level1/Level-1.xml # geändert: George.java # geändert: DefaultPassenger.java # # Nicht getrackte Dateien: # (verwenden Sie “git add …”, um das einzuschließen, was festgeschrieben wird) # # mb-art/originalAssets/27dec/

    – Lukas

    27. Dezember 2011 um 21:26 Uhr


  • Ich denke, Sie sollten GITKRAKEN verwenden, es wird Ihnen bei der Lösung Ihrer Konflikte helfen

    – Nikhil Bhardwaj

    16. April 2020 um 3:05 Uhr

Benutzer-Avatar
jonasfh

Dies geschieht, weil Sie beim Beheben eines Konflikts den gesamten Code im Patch entfernt haben, der auf den Zweig angewendet wird, auf den Sie rebasieren. Wenn Sie sicher sind, dass Sie alle Ihre Änderungen hinzugefügt haben: Verwenden git rebase --skip weitermachen.

Etwas mehr Details:

Wenn Sie einen Konflikt während der Rebasierung beheben, bearbeiten Sie normalerweise die konfliktbehaftete Datei und behalten einen Teil oder den gesamten Code im Patch, der derzeit auf den Zweig angewendet wird, auf den Sie rebasen. Nach dem Fixieren des Patches und tun

git add your/conflicted/file
git status

Sie erhalten eine (normalerweise grüne) Zeile, die die geänderte Datei anzeigt

geändert: Ihre/konfliktierte/Datei

git rebase –continue wird in dieser Situation gut funktionieren.

Manchmal entfernen Sie jedoch beim Lösen des Konflikts alles in Ihrem neuen Patch und behalten nur den Code aus dem Zweig, auf dem Sie rebasiert haben. Wenn Sie jetzt die Datei hinzufügen, ist sie genau so wie die, auf die Sie versucht haben, umzubasieren. git status zeigt keine grüne Linie, die die geänderten Dateien anzeigt. Nun, wenn Sie das tun

git rebase --continue

git wird sich beschweren

Keine Änderungen – hast du vergessen ‘git add’ zu verwenden?

Wenn Sie sicher sind, dass Sie alle Ihre Änderungen hinzugefügt habenwas Git in dieser Situation eigentlich von dir möchte, ist zu verwenden

git rebase --skip

um den Patch zu überspringen. Früher habe ich das nie gemacht, da ich mir immer unsicher war, was eigentlich übersprungen werden würde, war mir nicht klar, was „diesen Patch überspringen“ wirklich bedeutet. Aber wenn Sie keine grüne Linie mit bekommen

geändert: Ihre/konfliktierte/Datei

nach dem Bearbeiten der Konfliktdatei, Hinzufügenund git status ausführen, dann können Sie ziemlich sicher sein, dass Sie den gesamten Patch entfernt haben, und Sie können stattdessen verwenden

git rebase --skip

weitermachen.

Der ursprüngliche Beitrag sagte, dass dies manchmal funktioniert:

git add -A
git rebase --continue
# works magically?

… aber verlassen Sie sich nicht darauf (und fügen Sie keine übrig gebliebenen Dateien in Ihren Repository-Ordnern hinzu)

  • Seien Sie vorsichtig, wenn Sie den Befehl git rebase –skip verwenden, Sie könnten Ihre Arbeit (bearbeitete Dateien) verlieren.

    – Youness Marhrani

    8. Juli 2019 um 11:54 Uhr

  • Während --skip richtig ist, wenn die Konfliktlösung keine Änderungen für den Commit ergibt, ist dies bei dieser Frage nicht der Fall. Beachten Sie, dass die ursprüngliche Frage mehrere Dateien mit Änderungen im Bereitstellungsbereich enthält.

    – Agbodike

    13. Mai 2020 um 21:02 Uhr

  • Ich höre damit ganz auf, nachdem ich bemerkt habe, dass einige Änderungen, die ich vorgenommen habe, verworfen wurden. Mit Vorsicht verwenden.

    – jperl

    11. Februar 2021 um 9:54 Uhr

  • Dies zerstörte Konfliktlösungen, an denen ich Stunden verbracht hatte, und ich habe keine Ahnung, wie ich sie zurückbekommen soll.

    – Andreas Puglionesi

    2. September 2021 um 4:21 Uhr

  • Ich hatte eine einzelne Datei mit einem Konflikt während der Rebase. Ich habe es gelöst, aber dann eine Reihe anderer Änderungen vorgenommen, bevor ich versuchte, die Rebase fortzusetzen. Die Verwendung von “–skip”, wie hier beschrieben, führte dazu, dass ALLE meine Änderungen zerstört wurden und nichts umbasiert wurde. Musste mit Reflog wiederherstellen und verlor mindestens eine Stunde Arbeit. Vorsichtig sein

    – NSjonas

    8. September 2021 um 20:19 Uhr

Benutzer-Avatar
ScottyBlades

Ich habe diese Warnung erhalten, wenn ich Dateien ohne Staging hatte. Stellen Sie sicher, dass Sie keine nicht bereitgestellten Dateien haben. Wenn Sie nicht möchten, dass sich die nicht bereitgestellten Dateien ändern, verwerfen Sie die Änderungen mit

git rm <filename>  

  • So einfach könnte es ein Kommentar sein; so hilfreich sollte es eine Antwort sein. Vielen Dank!

    – Lukas Lima

    3. Dezember 2019 um 15:16 Uhr

  • OMG, das brauchte ich wirklich

    – Meenohara

    5. April um 10:01 Uhr

Scheint ein Fehler in Git 1.7 zu sein

Hier ist ein guter Artikel darüber, wie man das löst.

Grundsätzlich sollte es funktionieren, wenn Sie a

git diff

nachdem Sie Ihre Konflikte gelöst haben und dann

git rebase --continue

sollte arbeiten.

  • Das hat mir tatsächlich bei git v2 geholfen – nicht, weil der Fehler zurückkam, sondern weil die Rebase so viele Änderungen zu übernehmen hatte, dass ich nicht bemerkte, dass eine Datei fehlte git add. git diff hat das gezeigt, und ich könnte weitermachen 🙂

    – igorsantos07

    14. Juni 2021 um 0:47 Uhr

Nachdem Sie Ihre Änderungen korrigiert haben, vergessen Sie möglicherweise, „git add -A“ auszuführen.

git add -A
git rebase --continue

Stellen Sie nach dem Beheben des Konflikts sicher, dass die geänderten Dateien zu Ihren bereitgestellten Dateien hinzugefügt werden. Dies löste das Problem für mich.

  • Dies hat den Trick für mich getan. Ich überprüfte Sourcetree, nachdem ich die im OP beschriebene Nachricht erhalten hatte, und sah sofort die beiden im Befehlsfenster erwähnten Dateien dort als nicht bereitgestellt. Stellte die Dateien bereit, führte “git rebase –continue” aus und ich war wieder auf dem richtigen Weg.

    – Massenpunktnetz

    18. Oktober 2018 um 15:08 Uhr

Benutzer-Avatar
Batkins

Versuchen Sie, dies in Ihrer Befehlszeile auszuführen:

$ git mergetool

Sollte einen interaktiven Editor aufrufen, mit dem Sie die Konflikte lösen können. Einfacher als es manuell zu versuchen, und Git erkennt auch, wenn Sie die Zusammenführung durchführen. Vermeidet auch Situationen, in denen Sie versehentlich nicht vollständig zusammenführen, was passieren kann, wenn Sie versuchen, es manuell zu tun.

  • Dies hat den Trick für mich getan. Ich überprüfte Sourcetree, nachdem ich die im OP beschriebene Nachricht erhalten hatte, und sah sofort die beiden im Befehlsfenster erwähnten Dateien dort als nicht bereitgestellt. Stellte die Dateien bereit, führte “git rebase –continue” aus und ich war wieder auf dem richtigen Weg.

    – Massenpunktnetz

    18. Oktober 2018 um 15:08 Uhr

Benutzer-Avatar
karpi

Ich hatte gerade dieses Problem, und obwohl ich denke, dass es ein paar Ursachen geben könnte, hier ist meine …

Ich hatte einen Git-Pre-Commit-Hook, der Commits unter bestimmten Bedingungen ablehnte. Dies ist beim manuellen Commit in Ordnung, da es die Ausgabe des Hooks anzeigt, und ich kann es entweder beheben oder es mit commit –no-verify ignorieren.

Das Problem scheint zu sein, dass beim Rebasing rebase –continue auch den Hook aufruft (um die letzten Änderungen zu übernehmen). Aber rebase wird die Hook-Ausgabe nicht anzeigen, es wird nur sehen, dass es fehlgeschlagen ist, und dann einen weniger spezifischen Fehler ausspucken, der besagt: „Sie müssen alle Merge-Konflikte bearbeiten und dann mit git add als gelöst markieren.“

Um dies zu beheben, stellen Sie alle Ihre Änderungen bereit und versuchen Sie es mit einem „git commit“, anstatt „git rebase –continue“ auszuführen. Wenn Sie unter demselben Hook-Problem leiden, sollten Sie die Gründe für das Scheitern ermitteln.

Obwohl git rebase die Ausgabe von git hook nicht anzeigt, akzeptiert es interessanterweise ein –no-verify, um die Hooks zu umgehen.

  • Ich hatte ein ähnliches Problem. Nichts anderes hat hier für mich funktioniert, aber nur „Git Commit“ zu machen und dann abzubrechen, schien die Diskrepanz auf magische Weise zu lösen, und dann konnte ich „Git Rebase – Continue“ erfolgreich ausführen.

    – Pattivácek

    6. August 2012 um 20:11 Uhr

  • Nur fürs Protokoll, da ich kürzlich mit ähnlichen Problemen zu kämpfen hatte, git rebase akzeptiert --no-verify Möglichkeit. Es entfällt jedoch nur die pre-rebase Hook, aber diese Option wird bei den nachfolgenden Aufrufen nicht angewendet git commit.

    – pkrysiak

    23. Februar 2016 um 6:29 Uhr

  • Enthält einen gültigen Punkt (Commit-Änderungen), ist aber zu ausführlich für eine gute Antwort.

    – Jack Miller

    26. November 2019 um 8:44 Uhr

1326200cookie-checkGit rebase –continue beschwert sich, selbst wenn alle Merge-Konflikte gelöst wurden

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy