Wie rebase über bereits indexiert Zweig

Meine git Zweige sehen wie folgt aus:Wie rebase über bereits indexiert Zweig

master-*-*-*-*-*-*-implement_x 
\     \-*-further_foo_fixes_that_depend_on_x 
    \     \-*-*-further_bar_fixes_that_depend_on_x 
    \ 
    \-implement_x_rebased

es auf diese Weise beendet, weil ich meine Zweig dachte implement_x stromaufwärts zusammengeführt werden würde, wie es ist, aber ich wurde gebeten, es zu zerquetschen zu einem einzigen Commit, also implement_x_rebased. Allerdings habe ich bereits mehrere Branchen zur weiteren Fixierung und Entwicklung angefangen, die auf meine Arbeit angewiesen sind, während ich darauf warte, dass die implement_x zusammengeführt wird.

Jetzt möchte ich die weitere Arbeit an implement_x_rebased umbasen. Ich dachte, das war ein No-Op, da implement_x und implement_x_rebased im exakt gleichen Zustand waren - es würde keine Zusammenführungskonflikte geben, nur die Änderungen zwischen implement_x und further_foo_fixes_that_depend_on_x usw. auf implement_x_rebased anwenden. Es scheint jedoch, dass Git nicht so schlau ist, und es versucht, den ganzen Weg von der Basis neu zu erstellen - was zu unnötigen Merge-Konflikten führt.

Ich dachte, dass der einfache Ausweg rebase & die weiteren Korrekturen auf implement_x zerquetschen und sie dann beiseite schaffen, und wenden Sie die stashes zu implement_x_rebased, aber ich bin neugierig, ob es eine richtige Art und Weise ist git erkennen, dass implement_x und implement_x_rebased sind eigentlich in dem gleichen Zustand?

Quelle

2014-12-12 GolDDranks

Ich weiß nicht, perfekte Antwort für diese Frage, aber Cherry-Pick ist auch eine der Optionen. – shirakia

Ah. Cherry Picking ist definitiv einfacher und besser als das manuelle Auftragen von Diffs. Ich warte immer noch auf Antworten, die meine Frage direkt beantworten, aber wenn es für mich keine gibt, werde ich das akzeptieren, wenn du es postest. – GolDDranks

Bitte überprüfen Sie 'git rev-parse implement_x^{tree} implementieren_x_rebased^{tree}, um zu sehen, ob die beiden Commits wirklich den gleichen Inhalt haben. – jthill

Dies scheint eine Aufgabe für die --onto Option von git rebase zu sein.

git rebase --onto implement_x_rebased implement_x further_bar_fixes_that_depend_on_x

Möglicherweise möchten Sie in der git rebase manual Blick auf die --onto Beispiel haben.

Quelle

2014-12-12 18:16:51

In der Tat ist genau diese Art von Situation eines der Beispiele ('git rebase --auf Master next topic') in' git help rebase', abgesehen von der Tatsache, dass das Ziel der Rebase nicht nur ein Single-Commit ist Verzweigen Sie in diesem Beispiel, aber das ist nicht wirklich wichtig für das Beispiel. – twalberg

Meine Geschichte hat noch nie so gut ausgesehen! Herrlich. – GolDDranks

-1

Eine Möglichkeit, dies zu nähern wäre implement_x und implement_x_rebased die gleichen ersten zu machen, z.B .:

git checkout implement_x_rebased 
git merge implement_x

dann in Ihrem weiteren Korrekturen in gewohnter Weise verschmelzen. Die Verschmelzung von implement_x sollte aus Sicht des Codes ein NOOP sein (überprüfen Sie, dass git diff implement_x implement_x_rebased tatsächlich nichts produziert), aber Sie erfassen die Tatsache, dass die beiden zusammengeführt sind, was es Ihnen ermöglicht, alles andere einfach zu ziehen.

Wenn sie nicht ganz gleich sind, benötigen Sie möglicherweise die Option -s ours. Dies zeichnet auf, dass eine Zusammenführung ohne Zusammenführen des Codes erfolgt ist. VERWENDUNG MIT EXTREM VORSICHT.

Wenn dies nicht möglich ist, können Sie einfach git rebase verwenden, um die späteren Zweige auf implement_x_rebased zu rebasieren.

Das ist besser als Rosinenpicken als a) Sie Kirsche brauchen nicht jede einzelne Pick begehen, denken Sie daran, den Auftrag zu erhalten rechts usw. b) semantisch, Ihre git Baum macht mehr Sinn danach

Quelle

2014-12-12 15:49:00 abligh

Antwort

Verwandte Themen