Wie rebasiert man einen Branch von einem rebased Branch?
Lesezeit: 5 Minuten
Radu Murzea
Also meine Historie sieht so aus:
o---o---o---o master
\
o---o---o A
\
o B
Also zur Erklärung:
Ich habe Filiale A von dem aus gestartet wurde master
Ich habe Filiale B (mit nur 1 Commit), von dem aus gestartet wurde A
Was ich will ist folgendes:
o---o---o---o master
\
o---o---o A
\
o B
Was ich tat, war:
1).
git checkout A
git rebase master
Dies führte zu vielen Konflikten, bei denen nach einiger Zeit, die für die Behebung aufgewendet wurde, die folgende Geschichte auftauchte:
o---o---o---o master
\
o---o---o A
Das ist genau das, was ich wollte.
(Ich weiß nicht wo B ist gerade)
2).
Danach habe ich viele Squashes gemacht und die Reihenfolge der Commits geändert Aum den Verlauf so aussehen zu lassen, wie ich es möchte.
3).
Was ich jetzt auch machen möchte ist:
git checkout B
git rebase A
Dies scheint jedoch nicht zu funktionieren und ich weiß nicht warum. Wenn ich mache git log Ich sehe die Commits, die vor Schritt 1 vorhanden waren.
Außerdem bekomme ich die gleiche große Anzahl von Konflikten, die ich bereits in Schritt 1 gelöst habe. Ich habe viel Zeit damit verbracht, es noch einmal zu tun.
Dieses Beispiel wird empfohlen --ontowas ich gemacht habe:
git checkout B
git rebase --onto A
Aber das löscht das Commit-on B ganz und macht A und B auf denselben Commit verweisen, dh auf den letzten A.
Meine Frage ist: Wie kann ich B effektiv von A umbasieren, sodass es so aussieht, als hätte B von A aus begonnen? ? (was am Anfang auch stimmte).
Meine beste Vermutung ist, dass ich benutze --onto falsch. Oder dass ich etwas anderes verwenden sollte (z cherry-pick).
Thomas F
Kurze Antwort auf Wie kann ich B effektiv von A umbasieren, sodass es so aussieht, als hätte B von A aus begonnen? Vorausgesetzt, Sie wollen umziehen genau eine verpflichten:
git rebase --onto A B~ B
Wenn Sie umziehen möchten mehr als eins Commit-Nutzung:
git rebase --onto A old_A B
Der Rest der Antwort.
Ihr Zweig von B ist immer noch vorhanden (Sie können ihn überprüfen), aber sein Elternteil ist immer noch genau das Commit-Objekt that A war vorher.
Um eine grafische Darstellung davon zu sehen, verwende ich:
git log --graph --decorate --all
um alle Zweige zu sehen und wo sie sich in Bezug zueinander befinden.
Was du ursprünglich hattest:
o---o---o---o master
\
o---o---o A
\
o B
Was du jetzt hast:
o---o---o-----------o master
\ \
o---o---o(B~) o---o---o A
\
o B
In Bezug auf die Verwendung --onto, müssen Sie einen Start- und einen Endpunkt haben. verwenden:
git rebase --onto [target] [rebasing stops] [rebasing head]
git rebase --onto A B~ B
Und was Sie bekommen:
o---o---o----------o master
\ \
o---o---o o---o---o A
(old_A) \
o B
[branch_name]~ gibt den übergeordneten Commit der Verzweigung an.
Das B~ ist der Zweig, den Sie nicht ändern möchten. (Es ist zufällig das alte A)
Alternativ, wenn B der einzige Commit wäre, der A als Parent hatte (dh B ist das Ende einer Kette von Commits, die vom Master abzweigen), könnten Sie das tun
git checkout B
git rebase master
git checkout B~ # this is the commit before B (the A commit)
git branch -d A # remove the old A branch (it was rebased, and so is now invalid
git branch A # recreate the A branch on the commit that is based on the original A
Vielen Dank. git rebase --onto A B~ B hat funktioniert PERFEKT. Jetzt muss ich nur noch herausfinden, warum 🙂 😀
– Radu Murzea
8. August 2015 um 8:50 Uhr
Hinweis für diejenigen, die blind kopieren (wie ich es getan habe): Das zweite Argument muss zeigen old AAlso B~ funktioniert nur wenn B hat einen einzigen Commit – was hier der Fall ist. Ich stelle mir die Syntax gerne als vor git rebase --onto <new base> <old base> <head>; <old base> ist wo <head> derzeit Zweige aus, und <new base> ist, wo Sie es verzweigen möchten.
– Sam
19. März 2017 um 3:31 Uhr
Timmy Lin
Ich habe das gleiche Problem mit meinem Git-Flow und habe einen besten und schnellen Weg gefunden, dies zu tun.
Der verwirrendste Teil ist, wie man es macht (3) .. aber niemand hat eine klare Antwort darauf.
Ich glaube, viele Leute sind auf das gleiche Problem gestoßen wie ich, als wir versuchten, “rebase –onto” zu machen, fanden wir das Funktion1 (alt) gibt es eigentlich nicht!
git rebase --onto feature1 feature1(old) feature2
Die Lösung besteht darin, stattdessen Folgendes zu verwenden:
Hmmm, interessant, ich werde mir diesen Teil genauer ansehen, danke.
– Radu Murzea
27. Dezember 2018 um 8:08 Uhr
Tom Rees
Wenn Sie A bereits neu aufgebaut haben, sollte es so sein, dass B genau dort ist, wo Sie es verlassen haben. Der Zweig (ein Zeiger), der A war, wurde einfach an seine neue Position verschoben.
Was ich empfehlen würde, um B effektiv auf A umzubasieren, ist, wie Sie vorgeschlagen haben, “Cherry-Pick” zu verwenden. Dieser Befehl versucht, die in einem Commit vorgenommenen Änderungen auf den Zweig anzuwenden, auf dem Sie ihn ausführen.
Wenn also die Commit-IDs des Commit, auf das B ursprünglich verwies, „123456“ lauteten, würde ich empfehlen, Ihr aktuelles „B“ an die gleiche Stelle wie das neue „A“ zu verschieben git branch -f B A dann renne git cherry-pick 123456 wodurch die Änderungen auf A angewendet werden.
Ich glaube die --onto Das Flag wird verwendet, um den Zielort festzulegen, von dem aus die Commits angewendet werden. Es ist standardmäßig “upstream” (Quelle: http://git-scm.com/docs/git-rebase).
Ich stelle mir den Rebase-Befehl gerne wie folgt vor:
git rebase --onto <Starting here> <Apply all commits from HERE> <TO HERE>
Auf diese Weise wäre es wahrscheinlich einfacher gewesen, B auf Master umzubasen und dann A auf das Commit vor B zu verweisen.
git rebase master B
(da der Startpunkt (–onto) implizit ‘master’ ist)
dann zu verwenden git branch -f A B^ (das ^ bedeutet ‘das Elternteil von’)
13115500cookie-checkWie rebasiert man einen Branch von einem rebased Branch?yes
