Ich habe folgende Situation: Ich machte einige Commits in meinem lokalen Repository, und dann eine riesige Zusammenführung eines anderen Zweigs (~ 150 commits) in den Master - es hatte eine Menge Konflikte darin.
Nun möchte ich ein Commit, das ich vor der Zusammenführung gemacht habe, verschieben, um danach zu sein.
Normalerweise würde ich "rebase -i" dafür verwenden.
Leider ist das Standardverhalten, das One-Merge-Commit zu brechen, das tatsächlich 150 weitere commits hinzugefügt hat, um es in separate Commits zu master (ich verstehe, es ist wie wenn ich Rebase anstelle von merge verwenden würde) - was ist schlechtes Verhalten für mich aus verschiedenen Gründen.
Ich habe das Flag '-p' für Rebase entdeckt, das die Zusammenführungen bewahrt und mich sehr darüber gefreut hat. Unglücklicherweise hat dies die gleiche Zusammenführung wieder angewendet und meine ganze Arbeit in Konfliktlösung vergessen. Wieder - schlechtes Benehmen!
Gibt es eine Lösung für das, was ich will? Verwenden von "rebase -i" nach dem Zusammenführen, um bestimmte Commits neu zu ordnen oder zu bearbeiten, ohne dass ich meine Post-Merge-Vorgänge wiederholen muss.
Danke!
Hier ist was rerere -train.sh Skript, das ich in meinem Kommentar erwähnt habe - im Wesentlichen macht es die Zusammenführung, verwendet Ihre Auflösung, und lässt es einfach sehen. Sie können dies manuell nur für Ihren einzelnen Commit tun, wenn Sie möchten:
%Vor% Sie könnten aber auch rerere.enabled auf "true" setzen und diese Schritte abzüglich der direkten Aufrufe von " git rerere " ausführen - und Sie würden in Zukunft festgelegt werden, wobei die erneute Ausführung automatisch ausgeführt wird, wenn Konflikte aufgelöst werden. Das ist was ich tue - es ist großartig.
Wenn Sie das Skript direkt ausführen möchten, möchten Sie es wahrscheinlich mit Argumenten wie rerere-train.sh ^<commit before the merge> <current branch> ausführen. (Die ^commit -Notation bedeutet "gehe nicht darüber hinaus in die Geschichte", also macht es dir nichts aus für all die Zusammenführungs-Commits in deinem Repo.)
Wie auch immer Sie es tun, sollten Sie die gewünschte Auflösung erhalten. Das heißt, Sie können weitermachen und Ihre Rebase -i machen, und wenn Sie in den Konflikt geraten, wird RERE die REcorded REsolution erneut verwenden. Nur ein Heads-Up: Es hinterlässt immer noch die Dateien, die im Index als konfliktbehaftet gekennzeichnet sind, so dass Sie sie überprüfen können und sicherstellen, dass das, was es getan hat, Sinn macht. Sobald Sie dies getan haben, verwenden Sie git add , um sie einzuchecken, als ob Sie die Konflikte selbst gelöst hätten, und fahren Sie wie gewöhnlich fort!
Die git-rerere manpage enthält eine sehr schöne, lange Beschreibung des normalen Gebrauches von rerere, der nie wirklich aufruft - alles wird automatisch gemacht. Und eine Anmerkung, die es nicht betont: Es basiert alles auf Konflikthunks, also kann es eine Auflösung auch dann wiederverwenden, wenn der Konflikt an einem völlig anderen Ort endet, solange es immer noch den gleichen Textkonflikt gibt.
Ich habe ein Skript erstellt, um dies hier zu tun. Weitere Informationen zu bekannten Einschränkungen finden Sie in den offenen Problemen .
Sie müssen zuerst rerere-train.sh auf Ihrem PATH installieren. Auf Fedora ist dies mit:
Ich habe rerere-train.sh aus der Antwort von Benutzer @ Jefromi verwendet. Allerdings hatte ich diesen Fehler:
Von diesem Ссылка habe ich folgendes gesehen:
Michal Marek
Der git-sh-Setup-Helper wurde anscheinend nie von benutzt Skripte außerhalb von Git. Dies wurde mit git 2.10 offensichtlich:
Nach Herunterladen einer älteren Version - 2.3.4 portable - Es ist mir gelungen, rerere-train.sh work zu machen.