Use of Git and its operation commands
1, Git's built-in tools
- Git Bash: Unix and Linux style command line, most used and recommended
- Git CMD: Windows style command line
- Git GUI: git with graphical interface. It is not recommended for beginners. Try to be familiar with common commands first
Commands commonly used in Linux related to Git
cd，ls，pwd，mv，cp，rm，scp，touch，vim，ssh，sh
Git The current user's home directory is Linux root The user's home directory is/root Ordinary users use Where is your home directory/home/use
2, Git work area and its process
1. Initialization and configuration of local warehouse
Create a new directory on the desktop gitcode，Want to use Git To monitor gitcode Files in the directory, Initialization is required before configuration name and email 1.Entry Directory: cd Directory path (with double right slash) cd C:\\Users\\LYW\\Desktop\\gitcode 2.use Git Command to initialize the local warehouse (that is, create a new one in the current directory) Git Code base), this command only needs to be run once git init 3.View configurations (these configurations are Git\etc Medium) git config --list without name and email，We need to add it ourselves 4.add to name and email(Configure the user information when editing the submitted code), git config --global user.name "[name]" git config --global user.email "[email address]"
2. Git has three working areas locally
Working Directory, stage / index, Repository or git directory
If you add a remote git repository (Remote Directory) in the, it can be divided into four work areas
The conversion relationship between these four areas is as follows:
Workspace: The workspace is where you usually store the project code Stage or Index: The temporary storage area is used to temporarily store your changes. In fact, it is just a file to save the information to be submitted to the file list Repository: The warehouse area (or local warehouse) is a safe place to store data, which contains the data you submit to all versions. For example: where HEAD Point to the latest version put into the warehouse Remote: Remote warehouse, a server hosting code, can be simply regarded as a computer in your project team for remote data exchange
3. Git workflow
The workflow of git is generally as follows:
1. Add and modify files in the working directory;
2. Put the files requiring version management into the temporary storage area;
3. Submit the files in the staging area to the git warehouse.
Therefore, git manages files in three states: modified, staged, and committed
Example 1: create a new file for operation
Example 2: operate on existing files
Example 3: We tracked the records of two text operations. How do we view the submitted records?
# Displays the version history of the current branch $ git log
Example 4: if we want to go back to a version submitted earlier, and the text also goes back to that version, what should we do
git reset --hard Version serial number --hard Indicates a parameter. The parameter is the version serial number, and the serial number at the beginning is enough
The three local areas should be exactly the version pointed to by HEAD in git warehouse:
- Directory: a directory managed by Git, that is, a warehouse, containing our workspace and Git's management space.
- WorkSpace: directories and files that need to be versioned through Git. These directories and files form a WorkSpace.
- . Git: the directory where Git management information is stored. It is automatically created when initializing the warehouse.
- Index/Stage: staging area, or update area to be submitted. We can put all updates in the staging area before submitting to repo.
- Local Repo: local warehouse, a version library stored locally; HEAD will only be the current development branch.
- Stash: hidden. It is a working state saving stack, which is used to save / restore the temporary state in WorkSpace.
Create working directory and common instructions
Workspace is generally the folder you want Git to help you manage. It can be the directory of your project or an empty directory. It is recommended not to have Chinese.
For daily use, just remember the following six commands:
Four states of files
Version control is the version control of a file. To modify and submit a file, you must first know the current status of the file. Otherwise, you may submit a file you don't want to submit, or the file you want to submit is not submitted.
- Untracked: not tracked. This file is in the folder, but it is not added to the GIT library and does not participate in version control Through git add, the status changes to Staged
- Unmodify: the file has been stored and not Modified, that is, the contents of the file snapshot in the version library are exactly the same as those in the folder There are two places for this type of file. If it is Modified, it becomes Modified If you use git rm to remove the version library, it becomes an Untracked file
- Modified: the file has been modified. It is only modified without other operations This file also has two destinations. You can enter the staged state through git add. If you use git checkout, you will discard the modifications and return to the unmodified state. This git checkout takes the file from the library and overwrites the current modifications!
- Staged: staging status Execute git commit to synchronize the changes to the library. At this time, the files in the library and the local files become consistent, and the files are in unmodified state Execute git reset HEAD filename to cancel the temporary storage, and the file status is Modified
Ignore file
Sometimes we don't want to include some files into version control, such as database files, temporary files, design files, etc
Create a ". gitignore" file in the home directory. This file has the following rules:
- Ignore empty lines in the file or lines starting with a pound (#) are ignored.
- You can use Linux wildcards. For example, an asterisk (*) represents any number of characters, and a question mark (?) Represents a character, square brackets ([abc]) represent an optional character range, and braces ({string1,string2,...}) Represents an optional string, etc.
- If the name is preceded by an exclamation mark (!), Represents an exception rule and will not be ignored.
- If the name is preceded by a path separator (/), it indicates that the files to be ignored are in this directory, and the files in the subdirectory are not ignored.
- If the last side of the name is a path separator (/), it means that the subdirectory of the name in this directory, rather than the file, should be ignored (both the default file and directory are ignored).
#For comments *.txt #Ignore all txt, so the upload will not be selected! !lib.txt #But lib Except TXT /temp #Only the temp file under the project root directory is ignored, excluding other directories tempbuild/ #Ignore all files in the build / directory doc/*.txt #Doc / notes. Is ignored Txt but not Doc / server / arch txt
Git common commands
Warehouse
# Create a Git code base in the current directory $ git init # Create a new directory and initialize it as a Git code base $ git init [project-name] # Download a project and its entire code history $ git clone [url]
to configure
# Displays the current Git configuration $ git config --list # Edit Git profile $ git config -e [--global] # Set user information when submitting code $ git config --global user.name "[name]" $ git config --global user.email "[email address]"
Add / delete files
# Adds the specified file to the staging area $ git add [file1] [file2] ... # Adds the specified directory to the staging area, including subdirectories $ git add [dir] # Add all files in the current directory to the staging area $ git add . # Confirmation is required before adding each change # For multiple changes in the same file, you can submit it in batches $ git add -p # Delete the workspace file and put the deletion into the staging area $ git rm [file1] [file2] ... # Stops tracking the specified file, but the file remains in the workspace $ git rm --cached [file] # Rename the file and put the rename in the staging area $ git mv [file-original] [file-renamed]
Code submission
# Submit staging area to warehouse area $ git commit -m [message] # Submit the specified files in the staging area to the warehouse area $ git commit [file1] [file2] ... -m [message] # Submit the changes in the workspace since the last commit and go directly to the warehouse area $ git commit -a # Show all diff information when submitting $ git commit -v # Use a new commit instead of the last commit # If there are no new changes in the code, it is used to rewrite the submission information of the last commit $ git commit --amend -m [message] # Redo the last commit and include new changes to the specified file $ git commit --amend [file1] [file2] ...
branch
# List all local branches $ git branch # List all remote branches $ git branch -r # Lists all local and remote branches $ git branch -a # Create a new branch, but still stay in the current branch $ git branch [branch-name] # Create a new branch and switch to it $ git checkout -b [branch] # Create a new branch and point to the specified commit $ git branch [branch] [commit] # Create a new branch and establish a tracking relationship with the specified remote branch $ git branch --track [branch] [remote-branch] # Switch to the specified branch and update the workspace $ git checkout [branch-name] # Switch to previous branch $ git checkout - # Establish a tracking relationship between an existing branch and a specified remote branch $ git branch --set-upstream [branch] [remote-branch] # Merge the specified branch to the current branch $ git merge [branch] # Select a commit to merge into the current branch $ git cherry-pick [commit] # Delete branch $ git branch -d [branch-name] # Delete remote branch $ git push origin --delete [branch-name] $ git branch -dr [remote/branch]
label
# List all tag s $ git tag # Create a new tag in the current commit $ git tag [tag] # Create a new tag and specify the commit $ git tag [tag] [commit] # Delete local tag $ git tag -d [tag] # Delete remote tag $ git push origin :refs/tags/[tagName] # View tag information $ git show [tag] # Submit specified tag $ git push [remote] [tag] # Submit all tag s $ git push [remote] --tags # Create a new branch to point to a tag $ git checkout -b [branch] [tag]
see information
# Show changed files
$ git status
# Displays the version history of the current branch
$ git log
# Displays the commit history and the files that change each time a commit occurs
$ git log --stat
# Search submission history according to keywords
$ git log -S [keyword]
# All changes after a commit are displayed, and each commit occupies one line
$ git log [tag] HEAD --pretty=format:%s
# Display all changes after a commit, and its "submission description" must meet the search criteria
$ git log [tag] HEAD --grep feature
# Displays the version history of a file, including file renaming
$ git log --follow [file]
$ git whatchanged [file]
# Displays each diff related to the specified file
$ git log -p [file]
# Show last 5 submissions
$ git log -5 --pretty --oneline
# View submission records for all branches
git log --graph --pretty=oneline --abbrev-commit
# Displays all submitted users, sorted by submission times
$ git shortlog -sn
# Displays who modified the specified file and when
$ git blame [file]
# Show differences between staging and workspace
$ git diff
# Displays the difference between the staging area and the previous commit
$ git diff --cached [file]
# Displays the difference between the workspace and the latest commit of the current branch
$ git diff HEAD
# Displays the difference between two submissions
$ git diff [first-branch]...[second-branch]
# Shows how many lines of code you wrote today
$ git diff --shortstat "@{0 day ago}"
# Displays the metadata and content changes of a submission
$ git show [commit]
# Displays the files that have changed in a submission
$ git show --name-only [commit]
# Displays the contents of a file at the time of a submission
$ git show [commit]:[filename]
# Displays the most recent commits of the current branch
$ git reflog
Remote synchronization
# Download all changes to the remote warehouse $ git fetch [remote] # Show all remote warehouses $ git remote -v # Displays information about a remote warehouse $ git remote show [remote] # Add a new remote warehouse and name it $ git remote add [shortname] [url] # Retrieve the changes from the remote warehouse and merge with the local branch $ git pull [remote] [branch] # Upload specified local branch to remote warehouse $ git push [remote] [branch] # Forcibly push the current branch to the remote warehouse, even if there is a conflict $ git push [remote] --force # Push all branches to remote warehouse $ git push [remote] --all
revoke
# Restore the specified files in the staging area to the workspace $ git checkout [file] # Restore the specified file of a commit to the staging area and workspace $ git checkout [commit] [file] # Restore all files in the staging area to the workspace $ git checkout . # Reset the specified file in the staging area to be consistent with the last commit, but the workspace remains unchanged $ git reset [file] # Reset the staging area and workspace to be consistent with the last commit $ git reset --hard # Reset the pointer of the current branch to the specified commit, and reset the staging area, but the workspace remains unchanged $ git reset [commit] # Reset the HEAD of the current branch to the specified commit, and reset the staging area and workspace at the same time, which is consistent with the specified commit $ git reset --hard [commit] # Reset the current HEAD to the specified commit, but leave the staging area and workspace unchanged $ git reset --keep [commit] # Create a new commit to revoke the specified commit # All changes in the latter will be offset by the former and applied to the current branch $ git revert [commit] Uncommitted changes will be removed temporarily and moved in later $ git stash $ git stash pop
other
# Generate a compressed package for publishing $ git archive
The above commonly used commands are from the blog post "list of commonly used Git commands" by Mr. Ruan Yifeng