2 Stimmen

Git rebasing interaktiv nicht quetschen, wenn Schnellvorlauf verfügbar

Ich habe einen Zweig von master mit drei Änderungen und möchte ihn wieder auf master zurückbasen. Zum Beispiel:

$git checkout master
$git branch dev && git checkout dev
$<do 3 commits>
$git checkout master
$git rebase dev -i

Normalerweise würde -i mir die 3 Commits geben und mir erlauben, zu quetschen. In diesem Fall ist es jedoch nur "noop" und wenn die rebase abgeschlossen ist, sehe ich die drei Commits auf Master verschoben. Ich vermute, dass in diesem Fall, da der Vorgänger nicht abgewichen war, ein schneller Vorlauf möglich war, und so ist dies geschehen. Aber ich möchte die Commits zerquetschen.

Ich habe versucht, --no-ff zu verwenden, aber es bewirkt genau dasselbe wie in meinem ursprünglichen Fall (noop + no squashing).

Ich habe auch versucht (im Entwicklungszweig)

$git rebase -i HEAD~3
$git checkout master
$git rebase dev

Aber das ist wirklich mühsam, und ich muss wissen, wie viele Commits ich für den HEAD~X-Teil zerquetschen muss.

Fußnote: Der Grund, warum dies für mich wichtig ist, liegt darin, dass dieser gequetschte Änderungssatz in Gerrit überprüft werden soll. Wenn sie getrennt sind, wird die Überprüfung unmöglich.

3voto

Mark Longair Punkte 412179

Ich bin mir nicht ganz sicher, warum Sie einige der Dinge in Ihrer Frage tun, z.B. meinen Sie nicht wirklich $git branch dev && git checkout dev bevor Sie die Übertragungen vornehmen? Mit deiner Version erstellst du sie einfach auf master sowieso. (Wenn ich richtig liege, können Sie übrigens auch git checkout -b dev als Abkürzung).

Der Grund, warum Sie nur einen Noop bekommen, ist, dass git rebase versucht, alle Commits in der Datei aktuell Zweig, die nicht in dem Zweig sind, den Sie als <upstream> Argument. Wenn Sie also git rebase -i dev während master gibt es keine Übertragungen in master die nicht auf dev . Im Grunde genommen müssen Sie es umgekehrt machen. Ich würde wie folgt vorgehen:

git checkout dev
git rebase -i master
[... change to 'squash' all but the first of the actions ...]

Dann hat Ihr Entwicklungszweig nur einen gequetschten Commit und Sie können diesen in den Masterzweig einbinden, wenn Sie möchten.

Alternativ können Sie auch Folgendes verwenden git merge --squash :

git checkout master
git merge --squash dev
git commit -m "The changes from dev squashed into one commit"

Entonces master wird eine einzige neue Übergabe haben, die das Ergebnis der Zusammenführung von dev in Master zu einem Commit zusammengefasst, und dieser neue Commit wird nur einen Elternteil haben, anstatt ein Merge-Commit zu sein.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X