Ich habe zwei Zweige: Entwicklung und bug_fixes . Ich habe versehentlich den Zweig Entwicklung in bug_fixes zusammengeführt vor zwei bis drei Wochen und arbeite seitdem an bug_fixes , und ich habe die Änderungen in bug_fixes verschoben.
Nun muss ich den Zweig Entwicklung aufheben. Ich möchte eine reine bug_fixes Zweigstelle ohne commits-Formular Entwicklung Zweig. Durch Googlen habe ich folgende Szenarien entwickelt:
1) Stellen Sie das Commit wieder her, das den Zweig Entwicklung im Zweig bug_fixes zusammengeführt hat, aber es hat die Aufgabe teilweise erledigt. Die Commits vom Zweig Entwicklung können weiterhin im Zweig bug_fixes angezeigt werden, was nicht erforderlich ist.
2) Rebase und löschen Sie das Commit, das die Zusammenführung durchgeführt hat, aber es hat immer noch das gleiche Problem wie in Punkt 1 beschrieben. bug_fixes Zweig enthält immer noch die Commits von Entwicklung Zweig.
Gibt es eine Möglichkeit, das Zusammenführungs-Commit zu löschen, und all diese Commits, die im Zweig bug_fixes der Zweigstelle Entwicklung eingehen, werden ebenfalls gelöscht? Oder ist es nicht möglich?
WENN Sie wissen, welche Commits vom Entwicklungszweig kommen (zusätzlich zum Merge-Commit), können Sie ein git rebase -i (interaktives Rebase) aus dem letzten guten Commit von Bugfixes:
Die komplexere Alternative wäre ein git filter-branch , aber hoffentlich reicht das interaktive Rebase.
Im OP steht Fall , war der vollständige Befehl:
%Vor% -p ermöglicht das Beibehalten des Merge-Commits.
Ich würde den folgenden Ansatz versuchen:
Erstellen Sie zunächst eine Liste der Commits in beiden Zweigen:
%Vor% Zweitens identifizieren Sie in jedem Zweig die ID des letzten Commits, bevor Sie die Zusammenführung ausführen. Nennen wir diese Commits devel-0 und bugfixing-0
Dann bringen Sie Ihre Zweige in den Status vor dem zufälligen Zusammenführen:
An dieser Stelle haben Sie zwei saubere, aber veraltete Git-Zweige. Nun sollten Sie von log-devel.txt und log-bugfixing.txt alle Commits nehmen, die nicht in den aktuellen Zweigen enthalten sind, und sie zum entsprechenden Zweig hinzufügen. Um ein Commit mit der ID abc0123 zu Ihrem Zweig development hinzuzufügen, können Sie cherry pick verwenden :
Berücksichtigen Sie, dass die Commits besser zu den sauberen Zweigen in der gleichen Reihenfolge hinzugefügt werden sollten, in der sie dem Fehlerbehebungszweig hinzugefügt wurden, um die Anzahl der auftretenden Konflikte zu minimieren.
Sie müssen Ihre letzte Commit-Nachricht für bug_fixes vor merge wissen, wenn Sie den sha-Hash dann besser kennen.
Jetzt müssen Sie zuerst den sha Hash mit dem Befehl
finden$ git reflog
Die Ausgabe ist etwas wie
1fb5738 KOPF @ {10}: commit ...
4d47df6 KOPF @ {11}: commit ...
5f32c4b HEAD @ {12}: Zusammenführen ...
428f91d HEAD @ {13}: Kasse ...
5f32c4b HEAD @ {14}: Kasse ...
Der erste Teil ist der sha-Hash. In diesem Fall hat der Status vor dem Zusammenführen den Hashwert 428f91d
Nun werden wir im bug_fixes Zweig auf diesen Hashwert
zurückgesetztgit reset --hard 428f91d
jetzt wird es rückgängig gemacht
Lassen Sie mich das Szenario mit einem Beispiel unten beschreiben
Fehlerbehebungszweig: Revision 10
Zusammengefasster Dev-Zweig: Revision 11
Mehrfache Änderungen nach der Zusammenführung: Revision 12 - Revision 15
-
Jetzt gibt es 2 Schritte, die erledigt werden müssen (Einfache Methode ohne native native Befehle)
Gehen Sie zurück zu Revision 10
Klonen Sie den neuesten Code in einen Ordner mit dem Namen "neuste"
Klonen Sie Revision 10 in einen Ordner namens "rev10"
Entfernen Sie den gesamten Inhalt (außer .git-Ordner) vom letzten Ordner
Kopieren Sie den gesamten Inhalt (außer .git-Ordner) vom Ordner rev10 zum neuesten Ordner
Überprüfen des letzten Ordnerinhalts
Jetzt wird der Bug-Korrektur-Zweig den Inhalt der Revision 10 ohne Änderungen der Entwickler-Verzweigung haben
Optional - Zusammenführen von Revision 12 - Revision 15 in den Zweig bug_fix
Da wir zur alten Revision zurückgekehrt sind, ist die letzte Verpflichtung zum Bugfix-Zweig ebenfalls weg Diese Revisionen müssen manuell nacheinander in den Bugfix-Zweig
übernommen werdenTags und Links git github branch version-control branching-and-merging