The repo is now in a 'detached HEAD' state. The HEAD ref has been moved, and now points at commit b. With git checkout, the main ref is still pointing to d. Now let us execute and compare, both git checkout b and git reset b. The HEAD ref and main branch ref currently point to commit d. This example demonstrates a sequence of commits on the main branch. To better demonstrate this behavior consider the following example: Where git checkout solely operates on the HEAD ref pointer, git reset will move the HEAD ref pointer and the current branch ref pointer. How it worksĪt a surface level, git reset is similar in behavior to git checkout.
Now that we have followed this changeset through the three trees we can begin to utilize git reset. Executing git log will display the Commit History. Invoking git status at this point shows that there are no pending changes to any of the trees.
The changeset has been added to the Commit History. Here we have created a new commit with a message of "update content of resetlifecyclefile". $ git commit -am"update content of reset_lifecycle_file" update content of reset_lifecycle_file 1 file changed, 1 insertion(+) $ git status On branch main nothing to commit, working tree clean This snapshot also includes the state of the Staging Index at the time of commit. The git commit command adds changes to a permanent snapshot that lives in the Commit History. Let us examine the Staging Index content at this point. The git status command output displays changes between the Commit History and the Staging Index. It is important to note that git status is not a true representation of the Staging Index. Invoking git status now shows reset_lifecycle_file in green under "Changes to be committed". Here we have invoked git add reset_lifecycle_file which adds the file to the Staging Index. The git ls-files command is essentially a debug utility for inspecting the state of the Staging Index tree. To accurately view the state of the Staging Index we must utilize a lesser known Git command git ls-files. Git generally tries to hide the implementation details of the Staging Index from the user. This tree is a complex internal caching mechanism. This tree is tracking Working Directory changes, that have been promoted with git add, to be stored in the next commit.
They will be displayed in the red with a 'modified' prefix. Git status can be used to show changes to the Working Directory. These changes are currently a part of the first tree, "The Working Directory". Invoking git status shows that Git is aware of the changes to the file. In our demo repository, we modify and add some content to the reset_lifecycle_file. " to discard changes in working directory) $ echo 'hello git reset' > reset_lifecycle_file
0 kommentar(er)
