preface
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
command
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.
reminder:
- 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
summary
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.