![]() ![]() Performing an interactive rebase, or a regular rebase containing conflicting changes.Switching to a branch using the detached flag, i.e.Explicitly checking out a remote branch, i.e.Operations than can leave HEAD in detached state: See infographic below illustrating the difference between committing in attached vs detached state.Ī common misconception is that the message You are in 'detached HEAD' state is of erroneous tone, when in fact it just describes how HEAD is referencing the current snapshot. In detached state experimental changes can be made without impacting any existing branch. Default state is attached, where any manipulation to the history is automatically recorded to the branch HEAD is currently referencing. HEAD can be in either of two states, attached or detached, depending on if you've checked out a branch or not. HEAD is a pointer to the currently checked out branch or commit, it answers the question: Where am I right now in the repository? Or, in other words, it's Git's way of knowing on which commit to mirror your local Working Tree on, and whether you're currently working on a branch ( attached) or not ( detached). Since you don't have a branch attached to you, the branch won't follow along with you as you make new commits. If HEAD does point to a commit (or tag), even if it's the same commit (or tag) that a branch also points to, you (and HEAD) have been detached from that branch. Typically that is not a commit, it is a branch. It points to whatever you checked out, wherever you are. You can see the same representation of (HEAD -> branch) vs. We're still on the master branch, aren't we? What do you think, are we in a detached HEAD state? HEAD is still referring to a specific revision that is associated with a branch name. Checking out the commit directly (instead of the branch) gives us a comma instead of an arrow. ![]() OK, so there is a small difference in the output here. Git checkout a3c485d -q # (-q is for dramatic effect) When it is time to checkout the commit directly, just use whatever abbreviated hash you get from the first output (here it is a3c485d). You'll get something slightly different, but they key bits will be there. You can look at this graphically if you try the following exercise. You could be on the same commit as your master branch, but if HEAD is pointing to the commit rather than the branch, it is detached and a new commit will not be associated with a branch reference. If you make a commit in this state, master, no longer being attached to HEAD, will no longer move along with you. This is called a detached HEAD, because HEAD is pointing to something other than a branch reference. That's what happens when HEAD points directly to a commit. Normally you'll get something like this: ref: refs/heads/master You can see what it is pointing to by looking under the hood. It is attached to that branch, and when you do certain things (e.g., commit or reset), the attached branch will move along with HEAD. Typically HEAD does not point to a commit. HEAD can point to a commit, yes, but typically it does not. You haven't detached from the HEAD, you and your HEAD have detached from something else. If you ever find yourself thinking: "oh no, i'm in detached HEAD state! I've lost my HEAD!" Remember, it's your HEAD. That is not what a detached HEAD state is. To address one common misconception: you cannot detach yourself from HEAD. Whatever you do, if you have moved somewhere new in your commit history, HEAD has moved along with you. If you checkout something, HEAD will move. It follows you wherever you go, whatever you do, like a shadow. HEADis a symbolic reference pointing to wherever you are in your commit history. I thought I'd add my answer to clear it up. There is a, perhaps subtle, but important misconception in a number these answers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |