Git work Flow

Git work Flow

The general work flow is as follows:

• Clone a Git resource as a working directory.
• Add or modify a file on a cloned resource.
• If someone else modifies it, you can update the resource.
• Review the changes before committing.
• Commit the changes.
• After the modification is complete, if an error is found, you can recall the submission and modify and submit it again.

Git Workflow:

Git workspaces, staging area, and repository

Basic concepts:

• Workspace: The directory that you can see on your computer.
• Staging Area: English is called stage, or index. Usually stored in the "Git Directory" index file (. git/index), so we call staging area sometimes called index.
• repository: The workspace has a hidden directory. Git, this isn't a workspace, it's a git repository.

The relationship between the staging area and the repository in the workspace, repository, and version:

The left side of the diagram is the workspace and the repository on the right. The area labeled "Index" in the repository is staging area (stage, index), which is marked "master" as the directory tree represented by the master branch.

As we can see in this figure, "HEAD" is actually a "cursor" to the master branch. So the place where the HEAD appears in the command in the diagram can be replaced with master.

The objects identified in the figure is the Git object library, which is actually located in the ". Git/objects" directory, which contains the various objects and content created.

When the "git add" command is executed on a workspace modified (or added) file, the staging area tree is updated, and the workspace modification (or new) file content is written to a new object in the object library, and the ID of the object is recorded in the staging area file index.

When the commit operation (git commit) is executed, the staging area directory tree is written to the repository (object library) and the master branch updates accordingly. That is, the directory tree that master points to is the directory tree that staging area when committed.

When the "Git reset HEAD" command is executed, the staging area tree is rewritten and replaced by the directory tree that the master branch points to, but the workspace is unaffected.

When the git RM--cached <file> command is executed, the file is deleted directly from staging area and the workspace is not changed.

When you execute the "git checkout." or "Git checkout-<file>" command, the workspace file is replaced with staging area all or specified files. This is a dangerous operation that clears changes that are not added to staging area in the workspace.

When the git checkout head or git checkout head <file> command is executed, the files in the staging area and the workspace are replaced with all or part of the files in the master branch that head points to. This command is also extremely risky because not only will the uncommitted changes in the workspace be cleared, but uncommitted changes in the staging area will also be cleared.

Git work Flow