Detached HEAD meaning that the HEAD ref doesn’t point to the same commit as the branch ref that always follows the last commit in a development branch
IMO this is misleading, or incomplete.
HEAD is different from branches in that it can point to a commit or a branch. A branch always points to a commit.
When HEAD is in [branch] detached state, there is no branch to refer to/we can refer to. We are outside of branches.
From a use case perspective that may illustrate the difference:
When HEAD points to a branch, and I commit, I commit to that branch.
When HEAD points to a commit ([branch] detached HEAD), and I commit, I create a commit, and HEAD points to the new commit, but there is no branch pointing to it. (A followup is needed, e.g. creating a branch, or updating an existing branch, to keep the new commit discoverable even after we change what HEAD points to - e.g. by switching to a branch.)
I thought HEAD was just a ref
“refs” are stored in .git/refs/heads - but HEAD is not. In that sense, HEAD is not a ref like the others (branches and tags and whatever else you put there, like pull request references).
HEAD is either a reference or a reference to a reference. Branches are references.
HEAD is different from branches in that it can point to a commit or a branch. A branch always points to a commit.
That’s what I was saying.
When HEAD is in [branch] detached state, there is no branch to refer to/we can refer to. We are outside of branches.
You can still be in detached HEAD state and still be in a branch in a sense that your working tree reflects a commit that’s in a series of commit that follow a certain bifurcation. If that makes any sense.
But as soon as you make changes and commit, you create a “branch within a branch” though that “branch” doesn’t have a branch ref pointing to it.
IMO this is misleading, or incomplete.
HEAD is different from branches in that it can point to a commit or a branch. A branch always points to a commit.
When HEAD is in [branch] detached state, there is no branch to refer to/we can refer to. We are outside of branches.
From a use case perspective that may illustrate the difference:
When HEAD points to a branch, and I commit, I commit to that branch.
When HEAD points to a commit ([branch] detached HEAD), and I commit, I create a commit, and HEAD points to the new commit, but there is no branch pointing to it. (A followup is needed, e.g. creating a branch, or updating an existing branch, to keep the new commit discoverable even after we change what HEAD points to - e.g. by switching to a branch.)
“refs” are stored in .git/refs/heads - but HEAD is not. In that sense, HEAD is not a ref like the others (branches and tags and whatever else you put there, like pull request references).
HEAD is either a reference or a reference to a reference. Branches are references.
That’s what I was saying.
You can still be in detached HEAD state and still be in a branch in a sense that your working tree reflects a commit that’s in a series of commit that follow a certain bifurcation. If that makes any sense.
But as soon as you make changes and commit, you create a “branch within a branch” though that “branch” doesn’t have a branch ref pointing to it.