1. Local Git principle
Workspace, version library and staging area:
- As shown in the figure above, the left side is the work area, which can be seen in the computer;
- On the right is the version library, and there is a hidden directory in the workspace Git, which is not a workspace, but a git version library, as shown in the first red box in the figure below;
- The area marked "index" in the version library is the staging area, which is called stage or index in English. Generally stored in The index file (. git/index) in the git directory, so we sometimes call the temporary storage area index, as shown in the second red box in the figure below.
Branch:
- The directory tree marked "master" is the directory tree represented by the master branch. We can switch branches through the command git checkout xxx
- In the figure, we can see that "HEAD" is actually a "cursor" pointing to the master branch (which can be compared with the pointer in C + +). Therefore, the place where HEAD appears in the illustrated command can be replaced by master.
Object library (objects):
- The area identified by objects in the figure is git's object library, which is actually located in the ". git/objects" directory, which contains various objects and contents created.
- When the git add command is executed on the file modified (or added) in the workspace, the directory tree of the staging area is updated, and the content of the file modified (or added) in the workspace is written to a new object in the object library, and the ID of the object is recorded in the file index of the staging area.
After clicking add, the directory tree of the staging area is updated, that is to say The git/index file will be modified and displayed in the There will be one more file in git/objects directory, as follows:
Underlying changes corresponding to local Git related commands:
-
When git commit is executed, the directory tree in the temporary storage area is written to the repository (Object Library). For example, when HEAD points to the master branch, the master branch will update accordingly. That is, the directory tree pointed to by the master is the directory tree of the staging area at the time of submission.
-
When the git reset HEAD command is executed, the directory tree of the staging area will be overwritten and replaced by the directory tree pointed to by the master branch, but the workspace will not be affected.
-
When the GIT RM -- cached < File > command is executed, the file will be deleted directly from the staging area, and the workspace will not be changed.
-
When git checkout is executed Or the GIT checkout -- > < File > command will replace the files in the workspace with all or specified files in the staging area. This operation is dangerous and will clear changes in the workspace that have not been added to the staging area.
-
When git checkout HEAD is executed Or git checkout HEAD < File > command, all or part of the files in the master branch pointed to by HEAD will be used to replace the files in the temporary storage area and work area. This command is also very dangerous because it clears uncommitted changes not only in the workspace (add command), but also in the staging area (commit command).
2. Changes in the bottom layer of GIT common commands
-
git init initialization warehouse
Git uses git init command to initialize a git repository. Many git commands need to be run in Git repository, so git init is the first command to use GIT.
After the git init command is executed, the git repository generates a git directory, which contains all metadata of resources, and other project directories remain unchanged.
-
git clone
Copy a remote warehouse, that is, download a remote project -
git add . - Add files to the staging area (files change from red to green in idea)
-
git status: view the current status of the warehouse and display the changed files.
-
git commit: submit the staging area to the local warehouse.
-git log view submission records
-
git reset: fallback version
$git reset HEAD ^ # back all content to the previous version
$ git reset HEAD^ hello.php # fallback hello PHP file version to previous version
$git reset 052e # fallback to the specified version
3. More commands:
3.1git add
# Adds the specified file to the staging area $ git add <File path> # Add all modified and deleted files to the staging area $ git add -u [<File path>] $ git add --update [<File path>] # Add all modified, deleted and newly added files to the temporary storage area. Omitting < file path > is the current directory $ git add -A [<File path>] $ git add --all [<File path>] # View all modified, deleted but not submitted files and enter a sub command system $ git add -i [<File path>] $ git add --interactive [<File path>]
3.2git branch
# List all local branches, and the current branch is marked with "*" $ git branch # List all local branches and display the last submission. The current branch is marked with "*" $ git branch -v # Create a new branch based on the last commit $ git branch <Branch name> # Modify branch name # If the original branch name is not specified, it is the current branch $ git branch -m [<Original branch name>] <New branch name> # Force modification of branch name $ git branch -M [<Original branch name>] <New branch name> # Deletes the specified local branch $ git branch -d <Branch name> # Force deletion of the specified local branch $ git branch -D <Branch name>
3.3git checkout
# Switch to the specified branch that already exists $ git checkout <Branch name> # Create and switch to the specified branch and keep all submission records # It is equivalent to the combination of "git branch" and "git checkout" $ git checkout -b <Branch name> # Create and switch to the specified branch and delete all submission records $ git checkout --orphan <Branch name> # Replace the local changes, and the newly added files and contents that have been added to the staging area will not be affected $ git checkout <File path> git checkout yes git One of the most common commands, but also a very dangerous command, because this command will rewrite the workspace.
3.4git clone
# By default, a folder with the same name as the version library is created in the current directory and the version is downloaded to this folder $ git clone <Web address of remote warehouse> # Specify the directory of the local warehouse $ git clone <Web address of remote warehouse> <Local directory> # -b specifies the branch to be cloned. The default is the master branch $ git clone <Web address of remote warehouse> -b <Branch name> <Local directory>
3.5git commit
# Submit the files in the temporary storage area to the local warehouse, and call the text editor to enter the description of the submission $ git commit # Submit the files in the staging area to the local warehouse and add description information $ git commit -m "<Description information submitted>" # Submit all modified and deleted files to the local warehouse # Excluding files that are not tracked by the version library is equivalent to calling "git add -u" first $ git commit -a -m "<Description information submitted>" # Modify the last submitted description $ git commit --amend
3.6git config
# View configuration information # --local: warehouse level, - Global: global level, - system: system level $ git config <--local | --global | --system> -l # View the currently effective configuration information $ git config -l # Edit profile # --local: warehouse level, - Global: global level, - system: system level $ git config <--local | --global | --system> -e # Add configuration item # --local: warehouse level, - Global: global level, - system: system level $ git config <--local | --global | --system> --add <name> <value> # Get configuration item $ git config <--local | --global | --system> --get <name> # Delete configuration item $ git config <--local | --global | --system> --unset <name> # Configure user information in submission records $ git config --global user.name <user name> $ git config --global user.email <e-mail address> # Change the size of the Git cache # If the submitted content is large and the default cache is small, the submission will fail # Cache size unit: B, for example: 524288000 (500MB) $ git config --global http.postBuffer <Cache size> # When the git status/git diff command is called, the change status is highlighted or colored $ git config --global color.ui true # Configure to cache passwords. The default cache time is 15 minutes $ git config --global credential.helper cache # Configure password cache time # Cache time in seconds $ git config --global credential.helper 'cache --timeout=<Cache time>' # Configure long-term storage password $ git config --global credential.helper store Git There are three profiles: Warehouse level configuration file: in the warehouse .git/.gitconfig，This configuration file is only valid for the warehouse. Global profile: Mac System in ~/.gitconfig，Windows System in C:\Users\<user name>\.gitconfig. System level profiles: in Git Under the installation directory of( Mac The installation directory under the system is /usr/local/git)of etc In folder gitconfig.
3.7git diff
# Compare the difference between the current file and the file in the staging area, and display the changes that have not been staged $ git diff # Compare the difference between the files in the staging area and the last submission $ git diff --cached $ git diff --staged # Compare the difference between the current file and the last submission $ git diff HEAD # View changes since the specified version $ git diff <commit ID> # Compare the differences between the two branches $ git diff <Branch name> <Branch name> # View the changes of the two branches after they are separated $ git diff <Branch name>...<Branch name>
3.8git fetch
# Retrieve the latest versions of all branches of the remote warehouse to the local $ git fetch <Alias of remote warehouse> # Retrieve the latest version of the specified branch of the remote warehouse to the local $ git fetch <Remote host name> <Branch name>
3.9git log
# Print all submission records $ git log # Print records from the first submission to the specified submission $ git log <commit ID> # Prints the specified number of newly submitted records $ git log -<Specified quantity>
3.10git merge
# Merge the specified branch into the current branch and automatically submit a new one $ git merge <Branch name> # Merge the specified branch into the current branch without new submission $ git merge --no-commit <Branch name>
3.11git mv
# Rename the specified file or folder $ git mv <source file/folder> <Target file/folder>
3.12git pull
# Get the latest version from the remote warehouse and merge it locally. First, execute git fetch, and then execute git merge to merge the HEAD of the obtained branch into the current branch. $ git pull
3.13git push
# Push the branch of the local warehouse to the specified branch of the remote warehouse $ git push <Alias of remote warehouse> <Local branch name>:<Remote branch name> # Deletes the branch of the specified remote warehouse $ git push <Alias of remote warehouse> :<Remote branch name> $ git push <Alias of remote warehouse> --delete <Remote branch name>
3.14git remote
# List existing remote warehouses $ git remote # List the details of the remote warehouse and the URL address after the alias $ git remote -v $ git remote --verbose # Add remote warehouse $ git remote add <Alias of remote warehouse> <Remote warehouse URL address> # Modify alias of remote warehouse $ git remote rename <Alias of the original remote warehouse> <New alias> # Delete the remote warehouse with the specified name $ git remote remove <Alias of remote warehouse> # Modify the URL address of the remote warehouse $ git remote set-url <Alias of remote warehouse> <New remote warehouse URL address>
3.15git reset
# The staging area is reset, but the files are not affected # It is equivalent to withdrawing the contents updated to the staging area with the "git add" command from the staging area. You can specify the file # If no commit ID is specified, the default is the current HEAD $ git reset [<File path>] $ git reset --mixed [<File path>] # Change the direction of HEAD to the specified submission record, and the file is not modified $ git reset <commit ID> $ git reset --mixed <commit ID> # Change the direction of HEAD to the specified submission record, and the file is not modified # It is equivalent to calling the "git reset --mixed" command and then doing "git add" again $ git reset --soft <commit ID> # Change the direction of HEAD to the specified submission record, and the file is also modified $ git reset --hard <commit ID>
3.16git rm
# Removes the tracking specified file and deletes it from the folder in the local warehouse $ git rm <File path> # Removes the tracking specified folder and deletes it from the folder in the local warehouse $ git rm -r <Folder path> # Remove the tracking specified file and keep it in the folder of the local warehouse $ git rm --cached
3.17tag
# Print all labels $ git tag # Add a lightweight label to point to the reference of the submission object, and you can specify the previous submission record $ git tag <Label name> [<commit ID>] # Add a note label with descriptive information to specify previous submission records $ git tag -a <Label name> -m <Label description information> [<commit ID>] # Switch to the specified label $ git checkout <Label name> # View label information $ git show <Label name> # Deletes the specified label $ git tag -d <Label name> # Submit the specified label to the remote warehouse $ git push <Alias of remote warehouse> <Label name> # Submit all local labels to the remote warehouse $ git push <Alias of remote warehouse> –tags
3.18git revert
# Generate a new submission to undo a submission. All submissions before this submission will be retained. $ git revert <commit ID>