0

Do I understand what's detached HEAD is all about in GIT? I see it as follows.

HEAD points to the currently active branch. If I checkout (select) an earlier commit in the branch, HEAD's will store the hash of that commit (instead of branch name) - this is the situation called 'detached HEAD'. Now suppose I added a few commits after doing that and checkout back the master branch (that's where I was at the beginning).

Now, what's the exact reason I've lost the commits I'd just made? Is it because the commits only know its parents, not children? The solution is to create a new branch in detached HEAD state before doing commits, right? This way I'll be able to reference to the new commits made from that point.

Interesting source

user4205580
  • 564
  • 5
  • 25
  • 2
    A commit only know its parent, it can't know any children since the children have not been made so far :) It is a single linked list, one direction. A very nice answer I found recently about the detached head is [that one](http://stackoverflow.com/questions/5772192/how-can-i-reconcile-detached-head-with-master-origin#answer-5772882) – tworabbits Oct 18 '15 at 15:39

1 Answers1

0

The exact reason the new commits were lost is because by creating them in detached HEAD mode, there is no commit or tag that references them. Thus they cannot be found by log, for example.

To track the new commits you can create a new branch in detached HEAD state either before or after you have made additional commits. Alternatively you could tag the final commit before running checkout to switch back to master.

Note that the commits are not truly lost - not immediately at least. The reflog will have a record of where HEAD pointed at all times, even when not on a branch. However, after a long time it is possible that the unreferenced objects will be garbage collected to save space in the repository.

frasertweedale
  • 5,424
  • 3
  • 26
  • 38