Understanding and use of Git
1. Basic concepts
1.1. What is git
Git, the full name of GIT, is a distributed version control system. Git is usually used in programming. Git supports distributed deployment and can effectively and high-speed handle version management from very small to very large projects. The biggest difference between distributed and centralized is that developers can submit to the local. Each developer copies a complete git warehouse on the local machine through git clone.
Below we can give an easy to understand example.
For example, when you write a programming document locally, you find that some places need to be modified or deleted. Some people may modify it directly in the current file, and some people will copy a copy to modify it, and then delete the useless file. But when you find that the original file is better or another version is better, you may be at a loss.
At this time, using git tool is a smart move. We can build a version library locally. Whenever we need to modify, we can submit the previous version and indicate the characteristics of this version. In this way, there is only one programming document in the folder. When you need which version, just restore it in the version library.
1.2. Work area, temporary storage area, version library and remote warehouse
Git has four local work areas: Working Directory, stage / index, Repository or git directory, and git warehouse (Remote Directory). The conversion relationship between these four areas is as follows:
- Workspace: workspace is where you usually store project code
- Index / Stage: 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 version Library) is a safe place to store data, which contains the data you submit to all versions. Where HEAD refers to the latest version put into the warehouse.
- Version can be simply understood as a directory (a directory where many versions are stored). All files in the directory are managed by GIT. Git will track the modification and deletion of each file, so that the history can be tracked at any time or the modification can be restored at some time in the future.
- Remote: remote warehouse, a server hosting code, can be simply regarded as a computer in your project team for remote data exchange
Put another way: your local warehouse consists of three "trees" maintained by git.
- The first is your working directory, which holds the actual files;
- The second is the Index, which is like a cache area to temporarily save your changes;
- The third HEAD refers to the result after your last submission.
2. Workflow
2.1 business development workflow
1. Development process
- Pull the latest code to the local
- Create a feature on the develop ment branch_ xxx
- Submit the code locally and branch the function to the feature after the verification is passed_ XXX push to personal warehouse
- You need to pull before pushing the code, because other members may have pushed before. If there is a conflict, you need to resolve the conflict;
- Initiate a merge request on the web page and branch the function to Feature_xxx requests to merge the develop ment into the public warehouse
- Public warehouse merge feature_ After XXX, update the issue and notify the tester to pull the latest develop ment branch for testing
- The tester creates a test branch on the develop ment branch and writes test code for testing
- After the test is passed, the tester notifies the issue initiator to close the issue. If the initiator tester is the same person, the version release will be closed directly
- If the test fails, the tester shall update the issue and notify the developer for maintenance
- The team Leader merges the develop ment to the master once a day
2. Test verification
Verification in the development phase is a development work, and comprehensive functional verification is required before the version is officially released
- Administrators build beta on Development_ XXX version and release
- Testers test beta_xxx program, submit issue feedback
- After the test passes, the administrator merges the latest develop ment code into the master branch and into the release branch to release the official version of release_ xxx
- If the test fails, create a bugFix branch on the develop ment branch to fix it
- After the bugFix is fixed, synchronize the code to the master
3. Version maintenance
After the stable version is released, if you encounter bug s or functional requirements and need to build and republish a new version, take the following steps
- If it is a bug repair, create a bugFix branch directly on the release branch to repair it. After the repair, synchronize the repair code to develop ment and then update it to master
- If it is a functional requirement, create a Feature branch directly on the release branch for design. After design, synchronize the design code to develop ment and then update it to master
- The process of version maintenance is the same as the development process. It also needs to go through two stages: development and testing
4. Branching strategy
5. Branch description
- Feature: a function branch, which is created from the develop ment branch and can be deleted after merging
- Development: the develop ment branch is created from the master branch. Direct push is not allowed
- master: the code on the main branch can be compiled and run normally
- Release: release the branch. After the master branch passes the test, the code is merged into this branch and the official version is released
6. Work flow chart
2.12. 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
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.
GIT does not care about the specific difference between the two versions of the file, but whether the whole file has changed. If the file has been changed, a snapshot of the new version of the file will be generated when adding and submitting. The method to judge whether the whole file has changed is to calculate the verification sum of the file with SHA-1 algorithm.
1. 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
2. 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
3. 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
4. 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
The following figure well explains the transition of these four states:
1. New file - > untracked
2. Use the add command to add the newly created file to the staging area - > staged
3. Use the commit command to submit the files in the staging area to the local warehouse - > unmodified
4. If you modify a file in Unmodified status - > modified
5. If you remove a file in Unmodified status - > untracked
3. Git specific use
1. Create a new code base
# Create a new git code base in the current directory $ git init # Create a new directory and initialize it as git code base $ git init [project-name] # Download all the code for a project $ git clone [url]
2. Configuration
git settings file is gitconfig, which can be in the user's home directory (global configuration) or in the project directory (project configuration).
# 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]"
3. 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 (including deleting and adding records) $ 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] ... # The tracking of the file is stopped in the specified workspace, but the file is retained $ git rm --cached [file] # Rename the file and put the rename in the staging area $ git mv [file-original] [file-renamed]
4. 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] # Resubmit and enter the git editor to edit the message $ git commit --amend # Redo the last commit and include new changes to the specified file $ git commit --amend [file1] [file2] ...
5. 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]
6. 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]
7. View 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
# Displays all submitted users, sorted by submission times
$ git shortlog -sn
# Displays who modified the specified file and when
$ git blame [file]
# Show code 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
# Pull the code from the local master to update the current branch: the branch is generally the master
$ git rebase [branch]
8. Remote synchronization
$ git remote update --Update remote warehousing # 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
9. Revocation
# 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
reference resources
1,https://blog.csdn.net/lss6378/article/details/86774492
2,https://blog.csdn.net/unstorm/article/details/87980915
3,https://blog.csdn.net/qq_36048820/article/details/84649613
4,https://www.cnblogs.com/qdhxhz/p/9757390.html
5,https://www.jianshu.com/p/e57a4a2cf077
6,https://github.com/LebronAl/git-tips
7,https://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ==&mid=2247489338&idx=2&sn=6fdd8968003b8f59d43c09b72894e877&chksm=ebd62816dca1a1003dcefb6dae8296dd08924426fa6f12d09b8695922007fcb9bfa342c35bd1&scene=21#wechat_redirect