A colleague of mine just had this situation. In his case, there were commits in detached head --they work in R-Studio-- and the tool did warn them that they could create the branch with this and that SHA reference... but since the only option was "Close" --duh!! it was a info box-- they closed the dialogue and lost the info for ever...
Thanks to the reflog
command we could see that the changes were not lost. But in our case, the git branch
did not work as expected... or a incoming git pull
did mess it up somehow. We had to fish the changes from the reflog to the newly created branch:
git cherry-pick 0b823d42..3cce27fc
which placed all the commits we wanted in the branch. Then we could merge the branch into develop
without issues.
Just in case this is informative for anyone, we did identify the commits on detached head in the reflog
by looking at those in between the marked with "checkout" (which identify branch shifting):
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
Those we wanted were HEAD@{8}
to HEAD@{6}
(both inclusive). So we got them by:
git cherry-pick 0b823d42..3cce27fc
Then the usual merge solving and final commit left us with branch lost_changes hosting the detached-head work that we thought lost. Merging that into develop was fast-forward this time.