У моего коллеги была такая ситуация. В его случае были коммиты в отдельной голове - они работают в R-Studio - и инструмент предупреждал их, что они могут создать ветку с той и той ссылкой на SHA ... но поскольку единственным вариантом было "Закрыть" --ду !! это было информационное окно - они закрыли диалог и потеряли информацию навсегда ...
Благодаря reflog команде мы увидели, что изменения не пропали. Но в нашем случае git branchэто не сработало, как ожидалось ... или входящий git pullкак-то испортил его. Нам пришлось выловить изменения из рефлога во вновь созданную ветку:
git cherry-pick 0b823d42..3cce27fc
который поместил все нужные нам коммиты в ветку. Тогда мы могли бы developбез проблем объединить ветку .
На всякий случай, если это для кого-то информативно, мы идентифицировали коммиты на отдельной голове. в reflogфайле, посмотрев на те, которые находятся между помеченными «checkout» (которые определяют смещение ветки):
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
Те, кого мы хотели, были HEAD@{8} в HEAD@{6}(оба включительно). Итак, мы получили их:
git cherry-pick 0b823d42..3cce27fc
Затем обычное решение слияния и финальная фиксация оставили нам ветку lost_changes, в которой размещалась отдельная работа, которую мы считали потерянной. На этот раз слияние этого с разработкой было ускоренным.