Namely, commits refer only to their parents, and the contents of a branch are those commits (and only those commits) which can be reached by following the parent links. Some assumptions are implicit in this which are necessary for a thorough understanding of the commit graph. In addition, when I commit, master shall be updated.” The branch master is pointing to C, and I currently have checked out the contents of master. Which is to say: “The parent of C is B, and the parent of B is A. Normally, things look like this: C ← refs/heads/master ← HEAD The verbosity below will hopefully aid in understanding how HEAD and master are different: You can create a temporary branch at that commit, but HEAD will be directed away from master nonetheless. If you want to check out a commit which is not the head of a branch, you simply have to redirect your HEAD to point at that commit. Git’s HEAD is simply a pointer that says what’s in the working directory. Anything that's still in the reflog will not be garbage collected, and generally references are kept in the reflog for at least 30 days. If you have already switched back to the master branch, and realize that you forgot a stray commit, you can find it using git reflog, which will show you a history of what commits HEAD has pointed to over the last few days. You can create a branch referring to the head revision with git checkout -b branch. If you forget to do this, and create commits off a branch, there's no need to worry. Now your commits won't be lost, as they will be included in a branch, that you can easily refer to, and merge later on. So, instead of checking out a bare revision and getting a detached head, if you feel like you are going to make more commits, you should use git checkout -b branch B to create a branch and check it out. After a certain amount of time, git will consider it garbage, to be discarded the next time garbage collection runs. Since there's nothing referring to it, it can be hard to find, and git considers commits with no references to be abandoned (they happen quite commonly if you rebase, or squash patches in, or do other fun history manipulation they usually represent abandoned patches that you no longer care about). If we later decide to check out master again, there will be nothing referring to E. We can even create new commits but if we do so, there's no branch that we're on, so we can't point any branch at that new commit. Now let's check out B, giving us a detached HEAD.Įverything works fine here we can look at all of the files, build our program, test it, etc. All of our commits are now in master, and HEAD points to the new commit through master. Now if we commit, git will create a commit that has C as a parent (because that's the current commit, pointed to from HEAD via master), and will update master to point to that new commit. master is the current branch, so HEAD points to master, which points to commit C. Let's start out with 3 commits on master, A, B, and C. To help visualize, here's are some diagrams demonstrating how working on a detached head differs from working on a branch. You can create a new branch by running: git checkout -b newbranch ea3d5ed If you make commits that are not referenced by a branch, they can easily get lost, and will eventually be cleaned up by git's garbage collector, as nothing refers to them. If, however, you want to make more commits starting from that point, you should create a branch. Just remember to check out an actual branch before you make any commits ( git checkout master, for example), so that you don't create commits that are not included in any branch. If all you're doing is checking it out so you can build or test that revision, then there's nothing wrong with working with a detached head. It depends on what you want to do when you checkout that commit.
0 Comments
Leave a Reply. |