Ich tat git rebase masterdie in einer Datei gemeldeten Konflikte behoben und dann git add die Datei, um den Konflikt zu lösen. Dann habe ich es getan git rebase --continueund bekam das:
Anwenden: Unit-Test behoben
Keine Änderungen – hast du vergessen ‘git add’ zu verwenden? Wenn es nichts mehr zu inszenieren gibt, besteht die Möglichkeit, dass etwas anderes bereits die gleichen Änderungen eingeführt hat; Vielleicht möchten Sie diesen Patch überspringen.
Wenn Sie dieses Problem behoben haben, führen Sie “git rebase –continue” aus. Wenn Sie diesen Patch lieber überspringen möchten, führen Sie stattdessen “git rebase –skip” aus. Um den ursprünglichen Branch auszuchecken und das Rebasing zu stoppen, führen Sie „git rebase –abort“ aus.
Irgendeine Idee, was ich hier vermisse? Soll ich git rebase –skip ausführen?
Was tut ein git diff Show? Wenn es keine Unterschiede zeigt, hat Ihre Rebase zu einem leeren Commit geführt, und Sie können es sicher überspringen.
– cmbuckley
19. Februar 2014 um 19:08 Uhr
git diff zeigt nichts an.
– Segen
19. Februar 2014 um 19:42 Uhr
Wie unten erwähnt, ist es zu 99% sicher, dass es sich um den erwähnten Fehler handelt. Wenn Sie –skip tun, verlieren Sie den letzten Commit, Sie könnten natürlich alle darin enthaltenen Änderungen ausgraben und sie erneut implementieren, wenn Ihr Rebase abgeschlossen ist. Die Alternative ist --abort Confit-Wechsel machen und neu anfangen. 🙁
– T. Benjamin Larsen
19. Februar 2014 um 19:49 Uhr
making the confit-change ?? hm?
– Käse
27. Juli 2016 um 3:51 Uhr
Für mich git rebase --skip, git add .dann git rebase --continue wieder
– onmyway133
1. Dezember 2016 um 11:27 Uhr
janos
Wenn Sie sich in Mac OS X befinden, sollten Sie zuerst deaktivieren revisiondda es mitten in der Rebase mit Dateien in Ihrem Arbeitsbaum herumspielen kann, was zu unvorhersehbarem und fehlerhaftem Verhalten führen kann:
git config --global core.trustctime false
Das Problem wird in erläutert Dieser Artikelund ein großes Dankeschön an @nickfalk, der darauf hingewiesen hat.
Was Ihre Rebase betrifft, so ist eine solche Situation in der Praxis nicht ungewöhnlich. Versuchen wir, die Schritte des Geschehens zu durchdenken:
Wenn Sie den aktuellen Zweig auf einen anderen Zweig umbasen, verschiebt git den HEAD in den anderen Zweig und beginnt mit der Anwendung der eindeutigen Commits, die Sie in Ihrem aktuellen Zweig haben.
Beim erneuten Abspielen eines dieser Commits ist ein Konflikt aufgetreten. Sie haben es gelöst, aber als Ergebnis gibt es keine Änderungen zum Festschreiben, nichts zum Wiedergeben in diesem Festschreiben.
Praktisch bedeutet dies, dass Sie die Änderungen im aktuellen Commit, der wiedergegeben wird, abgelehnt haben. Wenn Sie also nichts von diesem Commit benötigen, ist es normal, es zu überspringen. So git rebase --skip macht hier Sinn.
Dies würde in der Tat Sinn machen, wenn der betreffende Commit nicht berücksichtigt und keine seiner Änderungen als Teil der Konfliktlösung akzeptiert würde. Unter Berücksichtigung des unten erwähnten bekannten Fehlers könnte dies jedoch auch bedeuten, dass Sie die beabsichtigten Änderungen in diesem Commit verlieren …
– T. Benjamin Larsen
19. Februar 2014 um 20:23 Uhr
Du hast Recht, ich habe diese Informationen jetzt hinzugefügt, und danke für den Hinweis!
– janos
19. Februar 2014 um 21:02 Uhr
Das machte mich wahnsinnig. Vielen Dank. Ich möchte auch erwähnen, dass Sie großartig sind.
– KommaToast
12. August 2014 um 17:23 Uhr
Eliseu Egewarth
Ich hatte ein ähnliches Problem in meinem Projekt und löste es, indem ich das setzte –preserve-merges Option für den rebase-Befehl. In meinem Projekt wurde dieses Problem durch einen Merge-Commit verursacht, der ein “leerer Commit” ist. Verwenden git rebase --preserve-merges es nimmt den Merge-Commit und fährt mit dem Merge fort, ohne den Commit-Baum zu unterbrechen.
Mann, das hat mir den Tag gerettet. Ich habe Ubuntu verwendet, daher traf keine andere Antwort auf mich zu als Ihre. Hinzufügen der --preserve-merges Option funktionierte einwandfrei, da git mir weitere Probleme zeigte, die ich mit meinem Baum hatte, die aber manuell behoben werden konnten.
– Alejandro de Haro
23. Januar 2020 um 12:06 Uhr
Gott segne Sie für diesen Beitrag. Es hat mein Problem gelöst!
– Damian Giebas
19. März 2020 um 14:09 Uhr
Das machte den Trick für mich auf Ubuntu
– nbeuchat
27. September 2021 um 10:19 Uhr
T. Benjamin Larsen
Atem, du wirst nicht verrückt! ;-= Dies ist ein bekannter Fehler, bei dem OSX (falls Sie das tatsächlich verwenden) mit Git herumspielt, er wird detailliert beschrieben hier (nicht von mir).
Kurzgeschichte (dh die Lösung) ist:
git config --global core.trustctime false
Früher hatte ich dieses Problem die ganze Zeit mit großen Rebases. Danke für den Hinweis!
– Josh Kovach
19. Februar 2014 um 19:30 Uhr
Ja OS X. Dieser Fix tut es nicht 🙁
– Segen
19. Februar 2014 um 19:40 Uhr
Es ist wahrscheinlich, dass dies bei Ihrem aktuellen Rebase nicht hilft. Es stützt sich bereits auf die vorhandenen Informationen im Dateisystem. Nicht sicher, aber es könnte funktionieren, wenn Sie die Rebase neu starten …
– T. Benjamin Larsen
19. Februar 2014 um 19:44 Uhr
@nickfalk, danke für die Beantwortung. Ich habe eine andere Antwort ausgewählt, weil das für mich die Lösung ist, aber Ihre Antwort kann jemand anderem sehr gut helfen.
– Segen
19. Februar 2014 um 20:11 Uhr
Keine Sorge, Boon, ich hoffe, du bist dir zu 100 % sicher, dass die Entscheidung, alle Änderungen, die dein erwähnter Commit hatte, zu ignorieren, das war, was du wolltest …
– T. Benjamin Larsen
19. Februar 2014 um 20:20 Uhr
Ich habe alle Methoden ausprobiert, aber nichts hat bei mir funktioniert. Wenn Sie sich nicht mitten in einer Rebase befinden, aber Git sich weiterhin beschwert, versuchen Sie Folgendes. Dies funktionierte für mich für OSX.
rm -fr ".git/rebase-apply"
git add . wird Sie aus diesem Zustand entsperren, aber wenn Sie alle Konflikte gelöst haben, indem Sie die eingehenden Änderungen akzeptiert haben, gibt es kein Diff hinzuzufügen, sodass git denkt, dass der Konflikt nicht gelöst wurde, was die Rebase betrifft.
Ich habe einen unauffälligen Ansatz gewählt, der funktionierte, ohne sich auf Nebenwirkungen der Verwendung mysteriöser Git-Konfigurationsänderungen usw. zu verlassen:
Harmlose Inhalte hinzugefügt (z // in einer Zeile) zu jeder Datei im Konflikt (um git etwas zu geben add)
git add .
git rebase --continue
harmlosen Kommentar entfernen
Alles sortiert 🙂
Neo
Es könnte durchaus bedeuten, dass die Änderungen bereits rebasiert sind. Überprüfen Sie einfach den Git-Status.
Keiner der oben genannten Vorschläge hat funktioniert. Ich habe herausgefunden, dass ich dieses Problem hatte, weil ich einen Hard-Reset des Master-Branch durchgeführt habe, während mein Feature-Branch einige Legacy-Master-Commits hatte (fragt mich nicht wie – keine Ahnung 🙁 ).
Ich habe meine Änderungen in ein temporäres Verzeichnis kopiert, meinen Feature-Zweig gelöscht, sie wieder hineinkopiert und von Grund auf neu gestartet. Hässlich, aber effektiv. Nicht empfohlen, wenn Sie versuchen, mehr als einen Commit in Ihrem Feature-Branch zu behalten. Nicht empfohlen, es sei denn, Sie haben es versucht ALLES ANDERE.
UPDATE: Das hat funktioniert, aber in den Kommentaren unten wurde ich auf einen besseren Ansatz hingewiesen. Schau mal.
Falls Sie Änderungen von einem einzelnen Commit (oder sogar wenigen) erhalten, ist es viel besser, sie in einen separaten temporären lokalen Zweig zu stellen, dann Ihren Arbeitszweig auszuchecken, ihn auf vor den Änderungen zurückzusetzen, bei Bedarf neu zu starten und dann Rosinen auszuwählen. Dafür ist Cherry Pick da – um Dinge nicht manuell zu kopieren.
– Adas Lesniak
16. März 2020 um 10:33 Uhr
@AdasLesniak, das ist ein wirklich guter Punkt! Ich wünschte, ich hätte daran gedacht, als ich letztes Jahr meine Probleme gelöst habe
– Gi0rgi0s
21. April 2020 um 19:40 Uhr
13111300cookie-checkgit rebase –continue funktioniert nichtyes
Was tut ein
git diff
Show? Wenn es keine Unterschiede zeigt, hat Ihre Rebase zu einem leeren Commit geführt, und Sie können es sicher überspringen.– cmbuckley
19. Februar 2014 um 19:08 Uhr
git diff zeigt nichts an.
– Segen
19. Februar 2014 um 19:42 Uhr
Wie unten erwähnt, ist es zu 99% sicher, dass es sich um den erwähnten Fehler handelt. Wenn Sie –skip tun, verlieren Sie den letzten Commit, Sie könnten natürlich alle darin enthaltenen Änderungen ausgraben und sie erneut implementieren, wenn Ihr Rebase abgeschlossen ist. Die Alternative ist
--abort
Confit-Wechsel machen und neu anfangen. 🙁– T. Benjamin Larsen
19. Februar 2014 um 19:49 Uhr
making the confit-change
?? hm?– Käse
27. Juli 2016 um 3:51 Uhr
Für mich
git rebase --skip
,git add .
danngit rebase --continue
wieder– onmyway133
1. Dezember 2016 um 11:27 Uhr