I'm not an expert with git (having mostly used mercurial which would never create this weird situation) but my understanding of this command is that it just says You need to do the checkout even though HEAD and myStuckBranch are now pointing at the same thing because you are still considered to be in the detached head state (not on a branch) The solution was just to do the following: git branch -f myStuckBranch HEAD I didn't want to change any of my history or do any cherry picking and I'd just spent about 8 weeks working on the branch so reset -hard was making me a bit nervous! It wouldn't let me push because I wasn't considered to be on the branch I thought I was on. If you have already shared changes with other people, you generally want to look at git revert instead, which generates an "anticommit" - that is, it creates a new commit that "undoes" the changes in question.įor some reason I ended up with a detached head - I had made commits on the same path as the branch I thought I was on - eg HEAD was a child of the branch tag but for some reason the branch tag had stayed back at a historic commit. However, if you are sharing the repository with other people, a git reset can be disruptive (because it erases a portion of the repository history). For example, this will reset the repository to the state of the previous commit, discarding any subsequent changes: git reset -hard HEAD^ If you want to discard changes that you have already committed, you may want to use the reset command. This will discard any uncommitted changes and revert the file to whatever state it has in the head of your current branch. If you have made changes to a particular file and you simply want to discard them, you can use the checkout command like this: git checkout myfile This is useful for examining the past state of the repository, but not what you want if you're actually trying to revert changes. When you check out a specific commit in git, you end up in a detached head state.that is, your working copy no longer reflects the state of a named reference (like "master"). So now we are in the same situation as in the start of this answer: with the commit pointed (directly or indirectly) by the HEAD. The content of the working directory is changed, too, to be in accordance with the appropriate commit (snapshot), i.e. This is the situation after performing those commands:Īs you can see, the HEAD points to the target of the git checkout command - to a branch (first 3 images of the quadruplet), or (directly) to a commit (the last image of the quadruplet). Now we want to perform git checkout - with different targets in the individual pictures (commands on top of them are dimmed to emphasize that we are only going to apply those commands): We begin with the same state of the repository (pictures in all quadrants are the same): To better understand situations with attached / detached HEAD, let's show the steps leading to the quadruplet of pictures above. it points to a branch, which in turn points to a commit), the HEAD is attached. If it points to a commit indirectly, (i.e.If it points to a commit directly, the HEAD is detached.it points to a branch).ĭetached HEAD means that it is not attached to any branch, i.e. HEAD is a pointer, and it points - directly or indirectly - to a particular commit:Īttached HEAD means that it is attached to some branch (i.e.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |