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)
