Ein Kollege von mir hatte gerade diese Situation. In seinem Fall gab es Commits in losgelöstem Kopf - sie arbeiten in R-Studio - und das Tool warnte sie, dass sie den Zweig mit dieser und jener SHA-Referenz erstellen könnten ... aber da die einzige Option "Schließen" war. --duh !! Es war eine Infobox - sie schlossen den Dialog und verloren die Informationen für immer ...
Dank des reflogBefehls konnten wir sehen, dass die Änderungen nicht verloren gingen. Aber in unserem Fall hat das git branchnicht wie erwartet funktioniert ... oder ein Eingang git pullhat es irgendwie durcheinander gebracht. Wir mussten die Änderungen vom Reflog zum neu erstellten Zweig fischen:
git cherry-pick 0b823d42..3cce27fc
das platzierte alle Commits, die wir in der Niederlassung wollten. Dann könnten wir den Zweig developohne Probleme zusammenführen.
Nur für den Fall, dass dies für irgendjemanden informativ ist, haben wir die Commits auf dem abgetrennten Kopf in der identifiziert, indem wir uns reflogdie zwischen den mit "checkout" gekennzeichneten Commits angesehen haben (die die Zweigverschiebung identifizieren):
e09f183b HEAD@{3}: pull: Fast-forward
b5bf3e1d HEAD@{4}: checkout: moving from lost_changes to develop
b5bf3e1d HEAD@{5}: checkout: moving from 3cce27fca50177a288df0252f02edd5da5ee64fd to lost_changes
3cce27fc HEAD@{6}: commit: add statistics
417a99a4 HEAD@{7}: commit: add test
0b823d42 HEAD@{8}: commit: new utility class
d9ea8a63 HEAD@{9}: checkout: moving from develop to d9ea8a635d4c2349fcb05b3339a6d7fad5ae2a09
b5bf3e1d HEAD@{10}: pull: Fast-forward
Diejenigen , wollten wir waren HEAD@{8}auf HEAD@{6}(beide inklusive). Also haben wir sie bekommen von:
git cherry-pick 0b823d42..3cce27fc
Dann ließen uns die üblichen Zusammenführungslösungen und das endgültige Festschreiben mit branch lost_changes zurück, in denen die Arbeit mit losgelöstem Kopf gehostet wurde, die wir für verloren hielten. Diesmal war es ein schneller Vorlauf, dies in die Entwicklung zu integrieren.
