High frequency command Git


Summarize the Git commands and postures I use frequently in the project.

It's not an introductory document. The official document must be more comprehensive than mine. Here is the output combined with the actual business scenario.

Git version used: git version 2.24.0



git log

Viewing logs, general operations, prerequisites:

# Output summary log. This command is equivalent to

# git log --pretty=oneline --abbrev-commit
git log --oneline

# Specify the last few submissions, which can be accompanied by - + numbers
git log --oneline -5

# Provide log display similar to GUI tools
git log --graph --date=relative --pretty=tformat:'%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%an %ad)%Creset'

git status

Viewing the status of the workspace is not as intuitive as the GUI, but the command line also has some functions:

# Equivalent to git status --long to view the changes in the temporary storage area of the current workspace
git status

# Summary information (- - short)
git status -s

# Query whether there are stash (temporary items) in the workspace. If yes, remind the workspace of several stash
git status  --show-stash

git checkout

It is used to switch to the corresponding record. It can be based on branch, submit and label.

Cut submissions and labels are generally used for hot fixes or new features need to be added to old versions.

# Branch switching
git checkout dev # local branch

# Switch remote branch
git checkout origin/test # remote branch

# Create a local branch based on the remote branch and track the corresponding remote branch from 'origin'
git checkout --track origin/feature-test # new local branch wih remote branch

# New branch based on local branch
git checkout -b testbranch # new local branch with current branch

# Discard changes to a file completely
git checkout -- file

# Discard all local changes
git checkout .

# Switch previous branch
git checkout -

git commit

The order to deal with every day. Here are some common postures.

# The newly modified content is added to the last submission to reduce the submission log
# --No edit: skip to the editor and submit directly
# git commit --amend this command is equivalent to
# $ git reset --soft HEAD^
# $ ... do something  tree ...
# $ git commit -c ORIG_HEAD
git commit --amend --no-edit

# Skip verification and submit directly, including any githooks
git commit --no-verify -m "xxx"

# With submission summary
git commit -m "xxx"

# Specify directory format submission
# -t <file>, --template=<file>
# You can also specify the submitted template file from the global or project level
# git config [--global] commit.template xxx
# Now, the npm specification package, commitizen and commitlint of the community are generally used to standardize submission
git commit -t templateFile

# The submission information is read from the file and can be used in combination with the above
git commit -F

git reset

It has to be said that this command is also used a lot in code rollback, and it is -- hard.

# Hard rollback, simple and crude, directly discard the changes after rollback (the log is still reserved, and the content is not needed)
git reset --hard commit_sha1

# Soft rollback has the same effect as rebase. You can throw the submitted items back to the temporary storage area and work area
# The direction of the HEAD will change to the corresponding commit, and then consider how to commit
git reset --soft commit_sha1

# A version of soft rollback can be understood as revoking the latest commit
git reset --soft HEAD~1

# Clear staging area but keep workspace changes
git reset --mixed commit_sha1

# Differences between reserved workspaces and staging areas
git reset --merge commit_sha1

# Preserve differences between workspace and HEAD
git reset --keep commit_sha1

git revert

It is generally used for code rollback of the master. Because many people cooperate on it, revert can roll back the code smoothly, but keep the submission record, so that the collaborators will not conflict with each other!

# Rollback to a commit
git revert commit-sha1

git rebase

Changing the base is very frequent in the project. Why do you say so.

For example, you develop a new feature and follow the concept of minimizing code submission.

When the whole function is developed, there will be a lot of commitments. rebase can make our commitment records very clean.

# With - i, you can enter the interactive mode. The effect is as follows
git rebase -i git-sha1|branch(HEAD)

# If there is no conflict in the middle, change the base in one step, otherwise it needs to be adjusted step by step.
git rebase --continue # Continue to change the base after submitting the change
git rebase --skip # The conflicting commitments will be discarded. If there is no need to change the continue prompt, you can also use this to skip
git rebase --abort # If the base change is disabled, but halfway through, you can completely roll back the state before the base change
  • pick: Yes, keep the commit (adopt)
  • edit: generally, you submit too many things. You can use this to take things back to the work area and split the finer commit
  • reword: this can modify your commit msg again
  • Square: keep the content and merge the submitted information into the previous commit
  • fixup: keep the changes, but discard the commit msg
  • drop: use less. Will you submit useless changes!

I suddenly found that there are several new behaviors in the screenshot. It is estimated that they are brought by the new version. Literally, it can be seen that the general meaning is to put rollback and labeling into the variable base to simplify the operation.


  • Before submitting locally, it is better to change the benchmark into the branch to be merged, so that there will be no conflict when submitting PR/MR (local to resolve the conflict)
  • Don't base on public branches! Once changed, other collaborators are basically a pile of conflicts! Unless you have a clear branch management mechanism.

git merge

# --ff refers to the fast forward command. When merging with ff mode, a new commit node will not be created.

# --No FF: keep the submission records of merged branches. Generally, the trunk is used more.

# --ff only unless the current HEAD node is the latest node or can be merged in ff mode, the merge is rejected and a failure status is returned.

# --Square is similar to rebase square, which can merge multiple commit s into one

git merge --no-ff branchName

git pull

git pull uses the method with -- rebase(-r) at most (pull the merge code in the form of variable base) to keep one branch line.

The default pull will follow the ff mode. In most cases, a new commit will be generated. Some parameters are consistent with those provided by merge.

git push

When the local branch exists and the remote branch does not exist, the associated remote branch can be pushed in this way.

# This will directly create a new remote branch with the same name
git push origin localbranch 

# Delete remote branch (- - delete)
git push -d origin branchName

# Push all tags
git push --tags

# Push the tags associated with the commit
git push --follow-tags

# Force push (- - force)
git push -f origin branchName # Generally, for reasonable projects, the trunk is protected by branches, and forced pushing is not allowed

# Sometimes it's really necessary to push, but can you be a little softer?
# That is, the current remote branch is consistent with your local branch. You can push it if no one else submits it
# --Force with lease: if someone remotely submits, the push fails, otherwise it succeeds
git push --force-with-lease

git remote

This tool is used when you need to consider maintaining multiple local warehouses or modifying the warehouse source.

# The gesture of associating the local git init to the remote warehouse in general
git remote add origin url

# Add other upstream warehouses
git remote add github url

# Modify push source
git remote set-url  origin(Or other upstream domains) url

git branch

This command is mostly used to delete local branches, rename branches and Delete remote branches.

# Branch deletion, copy, rename, if the parameter is capitalized, it is much the same -- force, enforce
# -c. -- copy: copy branch
# -C: Equivalent to -- copy --force
# -d. -- delete: delete branch
# -m. -- move: move or rename branches
git branch -d branchName
git branch -M oldBranch newNameBranch

# Manually specify the upstream branch of its current branch. The two are written in the same way
# Associated and generally de associated, -- unset upstream
git branch --set-upstream-to=origin/xxx 
git branch --set-upstream-to origin xxx 

git stash

The most time you use temporary storage is when you're halfway through the code and suddenly say that there's an emergency Bug to fix.

Or others need help to check the code here. You will also use it at this time.

It is strongly recommended to add description information to each stash!

# Cache the contents of the current workspace to stashName. save is not recommended now. It can also be used for convenience
# -a|--all: except for untracked files, other changed files will be saved
# -U | -- include untracked: includes files not added to the staging area
git stash save stashName
git stash -u save stashName

# Now it is recommended to use push, because pop is more clear in semantics and maintenance
# There are some parameters above. It also has - m to note the general situation of the stash
git stash push -m "Changed xx" 

# If there is preservation, there must be access
# pop: fetching will delete the corresponding saved record
# apply: get but keep records
# 0 is -- index. Where did this thing come from?
git stash apply stash@{0}
git stash pop stash@{0}

# View stash save record
# eg: stash@{0}: On dev: Test
git stash list

# What if you just want to delete the temporary record
# Clear: clear all stash
# drop: clears the specified stash
git stash clear # Use with caution!
git stash drop stash@{0}

# I want to see what changes have been made to stash, similar to the simplified version of git diff
git stash show stash@{0} 

git reflog

The power of this command is that it records all behaviors, including rebase, merge and reset.

When we accidentally hard roll back or change the base wrong, we can find the commit before the behavior here and roll back.

Of course, this time backtracking is only useful locally. Should you cool down the destructive changes you push to the remote branch.

# The last five behaviors without - n are all by default
git reflog -5

git cherry-pick

You can understand this thing as you go to buy oranges. You will specially pick some oranges that meet your heart and put them in the shopping basket.

You can pick up some required commit ments from multiple branches at the same time and merge them into the same place, right.

If there is only a conflict with the additional goods, there will be no conflict with the additional goods.

If there is a conflict, it will be interrupted. After resolution -- continue.

# Select the commit of other branches in the current branch and change that part
git cherry-pick commit-sha1

# Support taking more than one at a time
git cherry-pick master~4 master~2

# Support interval. In the middle of the interval is 
git cherry-pick startGitSha1..endGitSha1

# --Continue: continue to pick. Generally, this is required only after the conflict is resolved
# --Skip: skip the next behavior of entering the queue this time 
# --abort: completely abandon pick and restore the state before pick
# --quit: automatic change without conflict, don't conflict, exit this pick
# These states are similar to base changing. Resolve the conflict, continue, skip the processing, give up this pick, and do not output errors

git rm

The most used pose in the old version of this command is for re indexing The scope of gitignore.

# Delete the index of a file
# --cache will not delete the files in the hard disk, but the relationship between Git index (cache)!
git rm --cache -- file

# Recursively clear all indexes (which can also be understood as cache). This posture is suitable for re - indexing gitignore new scope takes effect
git rm -r --cached .  
git add .
git commit -m "xxx"

git rev-parse

This estimate is not widely used by ordinary people. You can quickly obtain the information of some Git warehouses through this.

I take things from here when I'm working on the script.

# Get the latest valid commit
# --short: displays the seven digit sha1, without which it is all
# --Verify: verify whether the commit is valid
# Head: the head point of the current branch
git rev-parse --short HEAD --verify

# Displays the absolute path of the warehouse
git rev-parse --show-toplevel #eg: /Users/linqunhe/Code/aozhe/thinking-ui

# Displays the version library Location of git directory
git rev-parse --git-dir

# Show git sha1 for all associated references
git rev-parse --all

git diff

This command is not frequently used in terminal comparison, except for a few changes.

In other cases, I prefer to use GUI tools because the comparison is more intuitive.

Guangzhou vi designhttp://www.maiqicn.com Complete collection of office resources websiteshttps://www.wode007.com


Git's common commands are actually easy to master. Many commands have the shadow of Linux.

The commands listed are used frequently. Maybe some more coquettish postures have not been found. If you have better suggestions, or if you find something wrong, please leave a message and correct it in time. Thank you for reading.

Tags: Front-end

Posted by manmanman on Sun, 15 May 2022 12:31:57 +0300