Coding With Fun
Home Docker Django Node.js Articles Python pip guide FAQ Policy

Git workspaces, staging areas, and repositories


May 25, 2021 Git


Table of contents


Git workspaces, staging areas, and repositories


Basic concepts

Let's start with the Git workspace, staging area, and repository concepts

  • Workspace: Is the directory you can see on your computer.
  • Staging area: English called stage, or index. It is generally stored in the index file (.git/index) under the "git directory", so we sometimes refer to the staging area as index.
  • Repository: The workspace has a hidden directory.git, which is not the workspace, but the Git repository.

The following diagram shows the relationship between the workspace, the staging area in the repository, and the repository:

Git workspaces, staging areas, and repositories

On the left side of the figure is the workspace and on the right is the repository. T he area marked "index" in the repository is the stage, index, and the area marked "master" is the tree represented by the master branch.

As we can see in the figure, "HEAD" is actually a "cursor" pointing to the master branch. S o where HEAD appears in the command shown can be replaced with master.

The objects in the figure identify the area as the Git object library, which is actually located in the ".git/objects" directory and contains the various objects and contents created.

When the "git add" command is executed on a file that is modified (or added) to the workspace, the tree of the staging area is updated, and the contents of the file that the workspace modifies (or adds) are written to a new object in the object library, and the object's ID is recorded in the file index of the staging area.

When a commit operation is performed, the staging tree is written to the repository (object library), and the master branch updates accordingly. T hat is, the tree that master points to is the tree of the staging area at the time of submission.

When the "git reset HEAD" command is executed, the staging tree is rewritten and replaced by the tree to which the master branch points, but the workspace is not affected.

When the "git rm-cached" command is executed, files are deleted directly from the staging area, and the workspace does not change.

When you execute the "git checkout ." or "git checkout -- slt;file," the files in the workspace are replaced with files that are all or specified in the staging area. T his is dangerous and clears changes in the workspace that have not been added to the staging area.

When you execute the "git checkout HEAD." or "git checkout HEAD" command, all or part of the files in the master branch that the HEAD points to are replaced with the staging area and the files in the workspace. This command is also very dangerous because not only will uncommitted changes in the workspace be cleared, but also uncommitted changes in the staging area will be cleared.