preface

Here is a summary of the git commands and gestures I frequently use in my projects.

This is not an introductory document, and the official document is certainly more comprehensive than mine. Here is the output combined with the actual business scenario.

Git version used: Git version 2.24.0

The command

git log

Viewing logs is a common operation, required

Output profile log. This command is equivalent to
# git log --pretty=oneline --abbrev-commit
git log --oneline

# Specifies that the last few submissions can have a - + number
git log --oneline -5

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


git status

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

= git status --long
git status

# Short (short)
git status -s

# Query whether any stash exists in the workspace. If so, it will remind you how many stash exist in the workspace
git status  --show-stash
Copy the code

git checkout

To switch to the corresponding record, can be based on branch, commit, label.

Cut commit and tag are usually used for hot fixes or when older versions require new features.

# Branch switch
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

Create 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 to the previous branch
git checkout -
Copy the code

git commit

Everyday commands, here are some common postures

# New content, added to the last commit, reduce commit log
# --no-edit: Is to skip to the editor and submit directly
# git commit --amend
# $ git reset --soft HEAD^
# $... do something tree ...
# $ git commit -c ORIG_HEAD
git commit --amend --no-edit

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

# with submit profile information
git commit -m "xxx"

# Specify directory format to submit
# -t <file>, --template=<file>
You can also specify the template file to be submitted at the global or project level
# git config [--global] commit.template xxx
# is commonly used now community code of NPM package, commitizen and commitlint to spec
git commit -t templateFile

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

git reset

I have to say that this command is also used a lot in code rollback, and it is –hard

# Hard rollback: simply discard the changes made after the rollback
git reset --hard commit_sha1

# Soft rollback, similar to the normal use of Rebase, can be thrown back to the staging area and workspace,
# HEAD = "commit"
git reset --soft commit_sha1

To roll back a version is to undo the most recent commit
git reset --soft HEAD~1

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

Retain the difference between workspaces and staging areas.
git reset --merge commit_sha1

Keep the difference between workspace and HEAD
git reset --keep commit_sha1

Copy the code

git revert

Generally used to roll back code for master, because many people are collaborating on it,

Revert can smoothly roll back code, but keep a record of the submission, without causing conflicts between collaborators!

# Rollback to a commit
git revert commit-sha1
Copy the code

git rebase

It’s very frequent in the program. Why is that?

For example, if you develop a new feature, follow the principle of minimizing code submission.

When the whole feature is developed, there will be a lot of commit, using rebase to keep our commit record clean

With -i, you can enter interactive mode
git rebase -i git-sha1|branch(HEAD)

If there is no conflict, change the base in one step, otherwise it needs to be adjusted gradually.
git rebase --continue # Commit the changes and proceed to the next step
git rebase --skip # Commits that cause conflict are dropped, and the continue prompt can also be skipped when no changes are required
git rebase --abort If the modification is crippled, but halfway through, the state before the modification can be completely rolled back
Copy the code

  • Pick: keep the commit
  • Edit: If you have a lot of commits, you can use this to bring them back into the workspace and split them into a smaller commit
  • Reword: This can be used to modify your commit MSG
  • Squash: Content is retained, and commit information is merged into a commit
  • Fixup: keep the changes, but discard the Commit MSG
  • Drop: use less, do you commit useless changes?!

Suddenly, I found that the screenshots also have several new behaviors, which is probably from the new version.

You can see what it means, basically, by putting things like rolling back and tagging into the base.

Tips:

  • Before committing locally, it is better to change the reference point to the branch that needs to be merged so that there is no conflict when committing PR/MR (resolving conflicts locally).
  • Do not base on the public branch!! A change of other collaborators are basically a bunch of conflicts! Unless you have a very clear branch management mechanism

git merge

# --ff is a fast-forward command that will not create a new commit node when merging in ff mode.
# --no-ff: keep the commit record for merge branches.
# --ff-only Reject the merge and return a failure status unless the current HEAD node is the latest or can be merged in FF mode.
--squash is similar to Rebase squash in that it can merge multiple Commits into one
git merge --no-ff branchName
Copy the code

git pull

Git pull is usually done with a –rebase(-r), keeping the branch one line.

The default pull will be in ff mode, which in most cases will result in a new COMMIT with some of the same parameters as the merge.

git push

When the local branch exists and the remote branch does not exist, you can push the associated remote branch in this way

This will 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 tags associated with commit
git push --follow-tags

# Force push (--force)
git push -f origin branchName * * * * * * * * * * * * * * * * *

# Sometimes you really need to push, but can you soften it?
The current remote branch is the same as your local branch. If no one else commits, you can force it
# --force-with-lease: lease is not a force-with-lease
git push --force-with-lease
Copy the code

git remote

This is used when you need to consider maintaining multiple local repositories, or when you need to modify the source of the repository

Associate local Git init to remote repository
git remote add origin url

# Add other upstream positions
git remote add github url

# Modify the push source
git remote set-url Origin (or another upstream domain) URLCopy the code

git branch

This command is most commonly used to delete local branches, rename branches, and delete remote branches

# Branch delete, copy, rename, arguments in uppercase are equivalent --force
# -c, --copy: copy branch,
# -c: equivalent to --copy --force
# -d, --delete: delete branch
# -m, --move: move or rename a branch
git branch -d branchName
git branch -M oldBranch newNameBranch


# Manually specify the branch upstream of its current branch
"(" unset-upstream"
git branch --set-upstream-to=origin/xxx 
git branch --set-upstream-to origin xxx 

Copy the code

git stash

The most you’ll ever use in temporary storage is when you’re halfway through your code and you say you need to fix an urgent BUG.

Or someone else needs help with code, and you’ll use it.

It is highly recommended to add a description to each Stash!!

# Cache the contents of the current workspace to stashName and save it to stashName
# - a | - all: in addition to not tracking file, other changes file will be saved
# - u | - include - untracked: including no files added to the staging area
git stash save stashName
git stash -u save stashName

# Push is basically recommended now, because pop is more clear in semantics and maintenance
It also has all the arguments above, and -m to note the general condition of this stash
git stash push -m "Xx changed" 

# Have to save that must also have to use
# pop: Fetching will delete the corresponding saved record
# apply: Retrieve but retain records
So # 0 is --index, where did that come from?
git stash apply stash@{0}
git stash pop stash@{0}

# stash Stash To save records
# eg: stash@{0}: On dev: test
git stash list


# What if I only want to delete the temporary record:
# Stash: Stash all
# drop: Clears the specified stash
git stash clear # with caution!
git stash drop stash@{0}

# Want to see what stash changes have been made, similar to git Diff lite
git stash show stash@{0}
Copy the code

git reflog

The power of this command is that it records all the behaviors, including your rebase,merge, reset and so on

If we accidentally hard roll back, or change the basis error, we can find the commit before the behavior, and then roll back.

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

Last five actions, without -n, default all
git reflog -5
Copy the code

git cherry-pick

You can understand this as if you go shopping for oranges, and you pick up the ones you like and put them in your shopping basket.

You can select from multiple branches and merge the required commit into one place.

This is similar to changing bases, but only similar. The selected commit is appended if there is no conflict.

If there is a conflict, it will be interrupted. When resolved –continue

Select a commit from the current branch and change that part of the commit
git cherry-pick commit-sha1

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

# Support intervals, the middle of which is..git cherry-pick startGitSha1.. endGitSha1# --continue: to continue the pick. This is usually required after the conflict is resolved
# --skip: Skip the next action to enter the queue
# -- Abort: Abandon the pick completely and restore the state before the pick
# --quit: automatic change if there is no conflict, do not quit this pick
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Copy the code

git rm

The most common gesture used by this command in older versions was to re-index the range of.gitignore

Delete index of a file
# cache does not delete files from the hard drive, it is just a git index (cache) relationship!!
git rm --cache -- file

# recursively clear all indexes. This posture is suitable for resetting the.gitignore range
git rm -r --cached .  
git add .
git commit -m "xxx"
Copy the code

git rev-parse

This estimate is not used by many people, you can quickly get some git repository information through this

I’ll take things from here when I’m working on the script

# Get the latest valid commit
# --short: shows 7 bits of SHA1
# --verify: verify whether the commit is valid
# HEAD: point to the current branch HEAD
git rev-parse --short HEAD --verify

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

Show the location of the repository. Git directory
git rev-parse --git-dir

# Display git sha1 for all associated references
git rev-parse --all
Copy the code

git diff

For this command, it is not used very frequently at the terminal, except for minor changes.

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

conclusion

Git’s common commands are actually pretty easy to follow, and many of them have Linux echoes.

The commands listed are frequently used, and there may be some more subtle gestures that are missing,

Please leave a message if you have better advice or find something wrong. We will correct it in time. Thank you for reading.