[Linux] git common commands

Time:2019-12-10

By logm

This article was originally published at https://segmentfault.com/u/logm/articles and is not allowed to be reproduced~

1. cloning

Git clone < version library URL >
Git clone < version library URL > <本地目录名>

#When cloning a version library, the remote host used is automatically named origin by GIT
#Use - O to modify the remote host name
Git clone - O < remote host name > < version library URL >

2. View history

#View every action in history
git reflog

#View history commit 
git log
git log --oneline

#View changes to commit
git show <commit_id>
git show --stat <commit_id>
git show <commit_id> <filename>

#View differences between two branches
git diff <branch1> <branch2>
git diff --stat <branch1> <branch2>

#View the changes of a file without adding
git diff <filename>

#See what changes have been made to the added file compared to the last commit
git diff --cached

3. Remote host management

#List all remote host names
git remote

#See the web address of the remote host
git remote -v

#View the detailed configuration of the host
Git remote show < hostname >

#Add remote host
Git remote add < host name > < web address >

#Delete remote host
Git remote RM < hostname >

#Remote host rename
Git remote rename < original hostname > < New hostname >

4. Branch management

#Fetch the new updates of the remote host back to the local, and all the updates of the branch by default
#The retrieved code has no impact on your local development code (just let 'git branch - a' show the newly added branch remotely without modifying the local code)
Git fetch < remote hostname >

#Retrieve the specific branch of the remote host
Git fetch < remote hostname > <分支名>

#View remote branches
git branch -r

#View all branches
git branch -a

#On the basis of origin / master, create a new local branch
git checkout -b newBrach origin/master
#Equivalent to execution
git branch newBrach
git checkout newBrach

#View tracking relationships
git branch -vv

#Manually establish tracking relationship
git branch --set-upstream-to=origin/remoteBranch localBranch

#Delete local branch
git branch -d <BranchName>

5. Pull back the update

#Retrieve the update of a branch of the remote host and merge it with the local specified branch
#In essence, this is the same as doing git fetch first and then git merge
Git pull < remote host name > < remote branch name >: < local branch name >

#With rebase mode, you can use the -- rebase option
Git pull -- rebase < remote host name > < remote branch name >: < local branch name >

#If the remote branch is merged with the current branch, the part after the colon can be omitted
Git pull < remote hostname > < remote branch name >

#If the current local branch already has a tracking branch on the remote host, you can omit the branch name
Git pull < remote hostname >

#If there is only one tracked branch, you can omit the host name
git pull

#If a branch is deleted by the remote host, GIT pull will not delete the corresponding local branch when pulling the remote branch by default
#Add the parameter - P to delete the remote deleted branch locally
git pull -p
To be equal to
git fetch --prune origin 
git fetch -p

6. Push update

#Push updates from local branches to remote hosts
Git push < remote hostname > < local branch name >: < remote branch name >

#If the remote branch name is omitted, the local branch will be pushed to the remote branch with which the tracking relationship exists. If the remote branch does not exist, it will be created
git push origin master

#If you omit the local branch name, the specified remote branch is removed because this is equivalent to pushing an empty local branch to the remote branch
git push origin :master
To be equal to
git push origin --delete master

#If there is a trace relationship between the current branch and the remote branch, both the local branch and the remote branch can be omitted
git push origin

#If the current branch has only one trace branch, the host name can be omitted
git push

#In another case, whether there is a corresponding remote branch or not, push all local branches to the remote host. In this case, you need to use the -- all option
git push --all origin

#If the version of the remote host is newer than the local version, GIT will report an error when pushing. You should first pull the merge code. If you have to push, you can use the -- force option
git push --force origin 

#Git push does not push tags unless you use the -- tags option
git push origin --tags

7. Code rollback

#The file was modified, but the GIT add operation was not performed
git checkout fileName

#The GIT add operation is performed on multiple files at the same time, but only a part of them are to be submitted this time
#Cancel staging
git reset HEAD <filename>

#The file performs the GIT add operation, but you want to undo the changes to it
#Cancel staging
git reset HEAD fileName
#Undo modification
git checkout fileName

#The modified file has been committed by git, but if you want to modify it again, no new commit will be generated
#Modify last commit 
$ git add fileName
$git commit -- amend - M "description"

#You have done git commit multiple times locally, and now you want to undo one of them
git reset [--hard|soft|mixed|merge|keep] [commit|HEAD]
#Hard: reset the index and working directory. Any changes in the working directory since < commit > are discarded. Point the head to < commit >
#The contents of soft: index and working directory do not change at all, just point the head to < commit >. All changes since < commit > are shown in "changes to be committed" in Git status
#Mixed: only index is reset, but working directory is not reset. This mode is the default mode, that is, mixed mode will be used when git reset mode is not displayed. The effect of this mode is that the changes of files in the working directory will be kept, not discarded, but not marked as "changes to be committed", but what reports will be printed that have not been updated

#Fallback local state to the same as remote
git reset --hard origin/devlop

#Revert is to discard the specified submitted changes, but a new submission will be generated, and the submission comments need to be filled in. The previous history records are all in;
#Reset is to point the head pointer to the specified commit, and there will be no abandoned commit record in the history.

Recommended Today

Kafka learning materials

Kafka 1、 Benefits of message middleware 1. Decoupling It allows you to extend or modify processes on both sides independently, as long as you make sure they comply with the same interface constraints. It would be a great waste to put resources on standby to handle such peak visits. The use of message queue can […]