0 background
This article is summarized in the git tutorial of gitcode.
1 History
In order to manage the code merging of the Linux system, Linus Torvalds used the distributed version control system BitKeeper at the beginning. Since the permission is withdrawn later, Linus firmly opposes CVS and SVN (although it is free, it is not only slow, but also must be connected to the Internet, and others need to be paid), So Linus used C to develop the distributed management system git in two weeks.
In 2008, GitHub website was launched. It provides git storage for open source projects for free. Countless open source projects began to migrate to GitHub, including jQuery, PHP, Ruby and so on. Let git grow.
2. Use of GIT configuration file
Custom configuration files are usually stored in the warehouse git/config file, and the GIT configuration file of the current user is placed in a hidden file in the user's home directory In gitconfig.
Example of global configuration file:
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = git@codechina.csdn.net:codechina/learngit.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[alias]
last = log -1
⚠️ Note: the alias is right after [alias]. To delete the alias, delete the corresponding line directly.
User profile:
$ cat .gitconfig
[alias]
co = checkout
ci = commit
br = branch
st = status
[user]
name = Your Name
email = your@email.com
[color]
ui = true
2.1 setting user name and email address
$ git config --global user.name "Miss Li" $ git config --global user.email li@csdn.net
2.2 view configuration
$ git config --list user.name= "Miss Li" user.email=li@csdn.net color.status=auto color.branch=auto color.interactive=auto color.diff=auto ...
You may see duplicate variable names because Git reads the same configuration from different files (for example: / etc/gitconfig and ~ /. Gitconfig)
You can also check a Git configuration by entering Git config < key >:,
$ git config user.name Miss Li
2.3 modify the configuration to ignore files (i.e. do not upload files) and force the upload of ignored files
The core point is modification gitignore file.
Here is an example Example of gitignore file:
# Windows: Thumbs.db ehthumbs.db Desktop.ini # Python: *.py[cod] *.so *.egg *.egg-info dist build # My configurations: db.ini deploy_key_rsa # Exclude all Hidden files at the beginning: .* # Exclude all class file: *.class # Not excluded gitignore and app class: !.gitignore !App.class
be careful ⚠️: Exclude specified files from The way to write outside the gitignore rule is+ File name.
The. gitignore file generally does not need to be written manually. Common configuration file information( link)
Check ignore rule:
$ git check-ignore -v App.class .gitignore:3:*.class App.class
Force upload of ignored files:
$ git add -f App.class
2.4 configuring aliases
For example, in the following example, st means status, cm means commit, etc. (-- global parameter is a global parameter, that is, these commands can be used in all Git warehouses on this computer.)
$ git config --global alias.st status $ git config --global alias.co checkout $ git config --global alias.ci commit $ git config --global alias.br branch
Once configured, you can use ci instead of commit.
$ git ci -m "sth."
Other common alias configurations:
$ git config --global alias.unstage 'reset HEAD' # $ git unstage test.py ## The actual execution is: $git reset head test py
3. Use git
3.1 create a version Library in the existing directory
# 1. Create file directory $ mkdir learning-git $ cd learning-git $ pwd /Users/xxm/learning-git # 2. Initialize warehouse $ git init Initialized empty Git repository in /Users/xxm/learning-git/.git/ # 3. Clone the existing warehouse # This will create a directory named help docs in the current directory and initialize a directory in this directory git folder, pull down all data from the remote warehouse and put it in git folder, and then read a copy of the latest version of the file from it. # git clone <url> $ git clone https://codechina.csdn.net/codechina/help-docs # Customize the name of the local warehouse and specify a new directory name through additional parameters (the following column is to replace help docs with mydocs) # $ git clone https://codechina.csdn.net/codechina/help-docs mydocs
3.2 uploading git
The following picture is from Liao Xuefeng's official website:
# 1. Upload files $ git add readme.txt # 2. Add description $ git commit -m "wrote a readme file" [master (root-commit) 50ed06b] wrote a readme file 1 file changed, 2 insertions(+) create mode 100644 readme.txt # 3. View the results submitted to the cache $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") # See what has been modified $ git diff readme.txt 4,Add branch to remote warehouse $ git push # The first version submission uses the following method # It will not only push the contents of the local master branch to the new remote master branch, but also associate the local master branch with the remote master branch # $ git push -u origin master
git push -u explain:
.
It mainly means branch< name>. Merge and branch< name>. Remote defines the upstream of a given branch. It tells git fetch/git pull which branch to merge, and can also affect git push
.
Upstream is the primary repository that others will get from, such as your GitHub repository- The u option automatically sets the upstream for you, linking your warehouse to a central warehouse. In this way, GIT will "know" where you want to push and where you want to extract information in the future, so you can use git pull or git push without parameters. When you git pull from a branch without specifying the source or remote branch, GIT will view the branch< name>. Merge settings to see where to extract. It is the git push -u command that sets this information for the branch you want to push.
.
So far, simply put, taking the - u parameter is actually equivalent to recording the default value of pushing to the remote branch, so that the push command can be abbreviated as git push when we want to continue pushing the remote branch next time.
3.3 modify commit submission
3.3.1 merge several commit submissions
Sometimes after submitting, we find that several files are missing and not added, or the submitted information is written incorrectly. At this point, you can run the submit command with the -- amend option to resubmit:
👉 git commit --amend
$ git commit --amend
This command will commit the files in the staging area. If you have not made any changes since the last submission (for example, you executed this command immediately after the last submission), the snapshot will remain unchanged, and all you have modified is the submission information.
For example, after submitting, you find that you forgot to temporarily save some required modifications. You can do the following:
$ git commit -m 'initial commit' $ git add forgotten_file $ git commit --amend
Eventually you will only have one submission - the second submission will replace the results of the first submission.
It's important to understand that when you fix the final submission, you don't fix it by replacing the old submission in situ with the improved submission. In effect, as if the old submission had never existed, it would not appear in the history of the warehouse.
The most obvious value of patching submission is that it can slightly improve your final submission without confusing your warehouse history with submission information such as "ah, forgot to add a file" or "minor patching, correcting clerical errors".
3.3.2 separate commit submission
You can use git reset head < File > To cancel staging to cancel staging readme Txt file:
$ git reset HEAD readme.txt
Unstaged changes after reset:
M readme.txt
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: LICENSE -> LICENSE.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
readme.txt file has been modified but not temporarily stored.
git reset is indeed a dangerous command, especially if the -- hard option is added. However, in the above scenario, the files in the working directory have not been modified, so it is relatively safe.
3.3.3 undo previous changes
Use the GIT checkout -- > File > instruction:
$ git checkout -- readme.txt
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: LICENSE -> LICENSE.md
You can see that those changes have been undone.
Remember that Git checkout -- < File > is a dangerous command. Any local changes you make to that file will disappear - Git will overwrite it with the most recently submitted version. Do not use this command unless you know that you do not want to make local changes to that file.
3.4 delete
3.4.1 it is really necessary to delete a file
$ rm test.txt $ git rm test.txt rm 'test.txt' $ git commit -m "remove test.txt" [master 5c7e5ea] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt
3.4.2 a file was deleted by mistake
$ rm test.txt # Restore the wrongly deleted file to the latest version from the version library $ git checkout -- test.txt
4 log
4.1 view recently submitted logs
$ git log
commit e55063ad7f97dd979e4f94e12d2bc44a25a0fd55 (HEAD -> master)
Author: Miykael_xxm <xiongjiamu@gmail.com>
Date: Fri Nov 27 16:08:04 2020 +0800
add distributed
commit 50ed06bd62fd34afbe501e6f2a4af73ccbe187f0
Author: Miykael_xxm <xiongjiamu@gmail.com>
Date: Fri Nov 27 16:06:11 2020 +0800
wrote a readme file
(END)
The git log command displays the latest and farthest submission logs. We can see two submissions, the latest one is add distributed, and the earliest one is write a readme file.
4.2 display log in Timeline mode
Automatically string git submissions into a timeline:
--pretty=oneline: displayed in one line, only the hash value and submission description are displayed
$ git log --pretty=oneline e55063ad7f97dd979e4f94e12d2bc44a25a0fd55 (HEAD -> master) add distributed 50ed06bd62fd34afbe501e6f2a4af73ccbe187f0 wrote a readme file (END)
More intuitive display:
--graph: displays the branch merge history represented by ASCII graphics
--Abrev commit: only the first few characters of SHA-1 are displayed
- pretty =: use other formats to display historical submission information. The options are: oneline,short,medium,full,fuller,email,raw and format: < string >, and the default is medium.
$ git log --graph --pretty=oneline --abbrev-commit * 082cad1 (HEAD -> master, origin/master, origin/HEAD) Merge branch 'master' of https://gitcode.net/qq_33375598/git-learning-course |\ | * d56e63b Merge branch 'feature1' into 'master' | |\ | | * 31b4c13 (origin/feature1) Creating a new branch is quick and simple. | | |\ | | |/ | |/| | | * 13dcd3e (feature1) ADD A SAMPLE * | | 0113c18 Modification conflict |/ / * | 7f34e0e & simple * | 9024f59 ADD A SAMPLE |/ * f2f9a97 Update README.md * 5d7e8d4 Initial commit
4.3 display reference log
git reflog
git relog interpretation:
.
Reflog is not a part of GIT warehouse. It is stored separately. It is purely local. (the contents displayed by the git reflog command should be stored in the. git/logs/HEAD file or in the. git/logs/refs directory.)
.
In other words, the git reflog command retains all the operations of the user in the local library starting from the clone warehouse.
5 version fallback
Principle: Git internally has a HEAD pointer to the current version. When you fallback the version, Git only points the HEAD from the to the fallback version.
5.1 fallback to previous version
$ git reset --hard HEAD^ HEAD is now at 50ed06b wrote a readme file
5.2 fallback to version number
git reset --hard commit-id
example:
$ git reflog
50ed06b (HEAD -> master) HEAD@{0}: reset: moving to HEAD~
e55063a HEAD@{1}: reset: moving to HEAD
e55063a HEAD@{2}: commit: add distributed
50ed06b (HEAD -> master) HEAD@{3}: commit (initial): wrote a readme file
ESC
$ git reset --hard e55063a
5.3 undo delete summary
Scenario 1: when you change the contents of a file in the workspace and want to discard the changes in the workspace directly, use the command git checkout -- file
Scenario 2: when you not only mess up the contents of a file in the workspace, but also add it to the temporary storage area, you want to discard the modification in two steps. In the first step, use the command git reset head < File >, and then return to scenario 1. In the second step, follow scenario 1
Scenario 3: when inappropriate modifications have been submitted to the version library, if you want to cancel this submission, you can use the command git reset --hard commit_id, but only if it is not pushed to the remote library