Rebasing abhängiger Themenzweige

Lesezeit: 2 Minuten

Ich verwende viele lokale Topic-Zweige in Git, und manchmal kommt es zu Abhängigkeiten zwischen Topic-Zweigen, die Rebase-Probleme verursachen. Zum Beispiel mit einer Struktur wie:

master ---> featureA ---> featureB
                     \--> featureC

Wenn master Änderungen und ich erhalte (und löse) Konflikte beim Rebasing featureAdann danach rebasing featureB auf zu featureA löst die gleichen Konflikte (und manchmal auch aufregende neue) aus, weil es versucht, die Patches aus dem neu anzuwenden featureA Zweig. Vorausgesetzt, die tatsächlichen Patches dazwischen featureA und featureB sauber anwenden würde, wenn es sich um eine Rosinenauswahl handelt, gibt es eine Möglichkeit, in dieser Situation eine Rebase durchzuführen, die ungefähr den gleichen Effekt hat wie die Rosinenauswahl aller Commits dazwischen featureA und featureB?

  • Sehen Sie auch, wie ich eine ganze Unterhistorie umbasieren würde – mehrere Zweige, mit einigen Verknüpfungen zwischen ihnen, die sich aus der Zusammenführung ergeben. Der unangenehme Teil dieser Lösung ist die Notwendigkeit, die Topic-Branch-Refs anschließend auf die neuen rebasierten Commits zurückzusetzen.

    – imz – Ivan Zakharyaschev

    14. März 2012 um 21:58 Uhr

Benutzer-Avatar
Phil

Nach der Umbasierung featureAdu kannst tun

git rebase --onto featureA oldFeatureA featureB

vorausgesetzt oldFeatureA repräsentiert das Commit an der Spitze von featureA bevor Sie es rebasieren (Sie können entweder einen anderen Zweig dort behalten oder sich einfach den Commit-Hash merken).

Dies sollte im Grunde dasselbe sein wie das Rosinenpicken jedes Commits zwischen A und B auf die rebasierte Version von A.

Dokumentation zu git-rebase (enthält einige hilfreiche bildliche Erklärungen dessen, was bei komplexeren Rebase-Operationen passiert)

  • Großartig, danke. Ich hatte herausgefunden, dass –onto so aussah, als sollte es die Arbeit erledigen, aber die alte Spitze als Basis zu verwenden, kam mir nicht in den Sinn.

    – Kai

    10. Oktober 2009 um 0:51 Uhr

  • Anstatt von oldFeatureAsollte nutzbar sein featureA@{1}, unter der Annahme, dass die Rebase die letzte Änderung an diesem Zweig war. Ansonsten verwenden Sie so etwas wie @{2}, @{3}oder @{one hour ago}

    – Ropez

    25. Juni 2010 um 8:38 Uhr

Wenn Sie in Zukunft mit vielen voneinander abhängigen Themenzweigen arbeiten, sollten Sie vielleicht die Verwendung von in Betracht ziehen TopGit (Liesmich), ein Tool zum Verwalten der Patch-Warteschlange mithilfe von Git-Themenzweigen, ein Patch pro Zweig; oder alternativ ein Tool zur Verwaltung mehrerer Themenzweige.

Siehe zB topgit bedeutet nie wieder auf Bewertungen warten zu müssen Blogeinträge.

  • Danke für den Hinweis auf TopGit! TopGit scheint auf das Richtige abzuzielen: die Aufrechterhaltung voneinander abhängiger Branches. Aber hat TopGit die Funktion, meine voneinander abhängigen Themenzweige auf einen neuen Upstream-Zustand umzubasieren? Wenn es möglich wäre, könnte ich TopGit verwenden, um meine Patches als Branches für eine Überprüfung und ein mögliches Pullen durch den Upstream zu entwickeln und vorzubereiten.

    – imz – Ivan Zakharyaschev

    14. März 2012 um 22:02 Uhr

  • Siehe auch Einige Diskussionen über ein “Rebase-basiertes TopGit”: “Ich denke, ein neues ‘System’ muss ‘rebase’-basiert sein, nicht fusionsbasiert wie TopGit”

    – imz – Ivan Zakharyaschev

    14. März 2012 um 22:30 Uhr

1090270cookie-checkRebasing abhängiger Themenzweige

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

Privacy policy