2017-08-09 11 views
1

Ich denke, ich mache etwas falsch, aber ich bin mir nicht sicher, wo. Ich habe einen funktionierenden Zweig und einen Meisterzweig. Der Arbeitszweig hat einige Commits, die noch nicht auf dem Master-Zweig sind. Jetzt habe ich einen kritischen Bugfix, den ich zu beherrschen begehe. Ich möchte auch dieses Commit in der Arbeitsbranche haben, deshalb verwende ich Rebase.TortoiseGit: Rebase mit Konflikt

Ich öffne das Rebase-Fenster in TortoiseGit und es zeigt dieses Commit. Nach dem Klicken auf "Start Rebase" informiert mich, dass mehrere Konflikte aufgetreten sind. Ich behebe die Konflikte und drücke "Commit" im Rebase-Fenster.

Jetzt wird das Commit im Commit-Protokoll angezeigt. Gut. Aber wenn ich es auf den Server schieben will, werde ich informiert, dass HEAD gelöst ist. Ich löse das mit git checkout -b temp und schiebe diesen temporären Zweig.

Wenn ich jetzt vom Ursprung abhole und das Rebase-Fenster wieder öffne, erscheint das Commit, das ich gerade gedrückt habe, wieder zum Rebase. Ich denke, es sollte dort nicht auftauchen, da es bereits rebasiert wurde.

Ich habe auch überprüft, wenn ein Commit ohne Konflikt, wird es nicht erneut im Rebase-Fenster angezeigt.

Was mache ich falsch?

+0

Bevor Sie den Rebase-Dialog öffnen, was ist der aktuelle Zweig (Checkout)? Dein Arbeitszweig? oder Meisterzweig? –

+0

arbeiten Sie in einem Submodul-Repository? –

+0

Beim ersten Rebase, hat Rebase "keinen Zweig"? –

Antwort

0

Wenn die Befehlszeilenschnittstelle: nach einer Fütterungsmaterial Konflikt Festsetzung Sie verpflichten müssen, und dann git sagen, „mit den übrigen Aktionen des aktuellen Fütterungsmaterials gehen“:

git rebase --continue 

Ich weiß nicht, was TortoiseGit tut oder nicht tut, sehen, wenn Sie eine Aktion haben, die wie „weiter rebase“ aussehen könnte, oder „fortsetzen rebase“ oder ...


eine andere Sache über Rebasieren: git nicht halten Überblick über die Commits, die bereits rebasiert wurden,
Stattdessen sieht es sich den Patch an, der von jedem neuzustellenden Commit eingeführt wird, und scannt den Zielzweig, um zu sehen, ob ein Commit den gleichen Patch bereits anwendet.

Wenn Sie einen Konflikt haben, ändern Sie im Allgemeinen etwas im resultierenden Patch, so dass das Re-Rebasing nicht erkennt, dass das ursprüngliche Commit tatsächlich angewendet wurde, und dieses Commit wird wieder angezeigt.

Eine Möglichkeit, dieses Problem zu vermeiden, ist Mergemaster in branch, statt Rebasing.

+0

Vielen Dank, ich habe nicht bemerkt, dass das Commit Änderungen von widersetzten Commits mit Konflikten hasht. Mit verschiedenen Hashes weiß git nicht, dass es das selbe ist. –

Verwandte Themen