Question about "master branch" terminology and detached HEAD state

Question about "master branch" terminology and detached HEAD state
0.0 0

#1

This is Git related.

The speaker in this video says that during the detached HEAD state, Git is warning you that you were looking at a commit that was not labeled with a branch name.

This is confusing to me because I thought the whole linear history of original commits was collectively the master branch. According to what the speaker said, this can’t be right because if I checkout an earlier commit, the branch has no label so thus it cannot be part of the master branch.

So what is the master branch? Is the master branch only the most recent commit? She always mentions the term “tip of the branch” in the video. Does this mean tip of the master branch and master branch are the same thing?

I think this is probably simple but I found her explanation confusing.

edit: Thanks for the explanations. I found this one to be particulary helpful, which I’ll copy and paste below:

"HEAD is a reference to the last commit in the currently checked-out branch.

There is a small exception to this, which is the detached HEAD. A detached HEAD is the situation you end up in whenever you check out a commit (or tag) instead of a branch. In this case, you have to imagine this as a temporary branch without a name; so instead of having a named branch reference, we only have HEAD. It will still allow you to make commits (which will update HEAD), so the above short definition is still true if you think of a detached HEAD as a temporary branch without a name."


#2

This GIT warning is most likely to occur when you checkout from the branch and work on the code and meanwhile a commit is performed on the same branch. This means the check-ed out code at your end is older. Now when you try to commit YOUR changes, there is obviously a conflict. Hence GIT warns you.
There are two options now, either checkout a fresh copy and then edit and commit the code or overwrite the code with yours. To perform the latter, you may have to reset the HEAD.
I would recommend delving into the folder .git, in particular the file HEAD and the folder refs. (Found in the folder where you initialized GIT. ‘ls -a’ will show the folder) It will help in learning more on how GIT works. I learnt the same way!


#3

The name “master” is arbitrary, but in a sense is a great default for the default branch. Tip of the branch or HEAD just signifies the last commit on a branch, named or not (you can even use it in place of a commit’s sha1 sum). IOW a branch is a series of commits, but only one can be in the front.

If you checkout an earlier commit, you’re still on the same branch, just back in time. Git is warning you about the classical time travelling paradox. :slight_smile: Any work made would either require rewriting the branch’s history or the creation of a new branch, otherwise it can get lost once you go back to some other HEAD (but git reflog can help).


#4

Thanks! Your explanation was very helpful, but I found this part a bit confusing:

If you checkout an earlier commit, you’re still on the same branch

As a Git newbie I find it much easier to conceptualize it like this:

A detached HEAD is the situation you end up in whenever you check out a commit (or tag) instead of a branch. In this case, you have to imagine this as a temporary branch without a name; so instead of having a named branch reference, we only have HEAD.

So I think it’s saying if you checkout an .earlier commit, a new temporary branch is made, rather than being on the same branch. Therefore, it’s detached from the branch you were previously on and since this new temporary branch has no name, it’s just HEAD. At least, that’s how I understand it. I found that explanation here.


#5

You need to create a new branch if you want to keep changes made to a detached head.

git checkout -b <new branch name> creates new branch from detached head and switches to that branch. You can create a new commit on the new branch then merge it. I think -b tells git to switch to the new branch after it’s created.

Try it out see if it works.


#6

That’s right, that’s exactly how it was described to me in the Git course I’m taking.

You can create a new commit on the new branch then merge it.

That’s how I figured you incorporated detached HEAD commits, but you just completed the circle for me. Thanks a bunch for the explanation :slight_smile:


#7

@ellereeeee I took the same course. Finished it last week. It was great. They really make you think about what you are doing in order to understand git instead of throwing commands at you.