Practical Git commands combed out from work

“This is the second day of my participation in the Gwen Challenge in November. See details: The Last Gwen Challenge in 2021”

I searched git tutorials online and found dozens of them, but I still wanted to write another git article for two reasons. One is that they are easy to write and easy to use. Second, most of the tutorials I see are not very down-to-earth, either listing the basic commands, or just a detailed analysis of a few commands. I want to write a Git operation guide that can cover my daily work scenes. If I forget how to type commands, I just need to open this article.

Git experiment

When you really forget what a certain command looks like, in addition to searching the official documentation or someone else’s experience with it, it can be proven from practice, Learn Git Shoot is a website where you can type a Git command and then intuitively see how the branch changes on the page. Git commands are recommended to help you learn how to use git commands more quickly.

Pre – work

The way to install Git goes without saying, but if you’re a front-end worker like me, you can configure VSCode as a git text editor.

git config --global core.editor "code --wait"
Copy the code

This works if you add vscode to the environment variable.

If you already have VISUAL studio code, you can download the GitLens plugin. Git Rebase provides an interactive rebase interface, as well as information about the most recently committed author of the current line of project code.

Also, if you use one of the git commands mentioned in this article and you can’t find it, check to see if your Git version is too old.

Pull the code

git cloneThe < url > warehouseCopy the code

Generally, warehouses of companies build GitLab warehouses on the Intranet, and identity authentication is indispensable for pushing codes. SSH authentication is commonly used. The general process is as follows: Create a pair of SSH keys (public key and private key), configure the public key to GitLab, and put the private key in the. SSH directory.

The command for creating a key is as follows:

ssh-keygen -t rsa -C "Key comment"
Copy the code

The -t parameter specifies the encryption algorithm, which uses RSA (an asymmetric encryption algorithm that uses large numbers of factors to ensure decryption), and -c specifies the key comment, which is unnecessary when many people on the Internet write their email addresses in comments. Because there is no -f parameter to specify the file name, you will be prompted interactively to enter the file path name, which is the default. You will also be prompted to enter passphrase. If there is no special requirement, just press Enter to skip it. By default, two files id_rsa and id_rsa.pub are created in the.ssh folder of the user directory (CD ~/. SSH can be switched to this directory). Pub suffix is a text file that stores public key information, and a file that does not have this suffix is a text file that stores the private key. To complete the configuration, copy and paste the text of the public key file into gitlab where you configured the SSH public key (which you will find on the Settings page). The advantage of using the default file path is that when git push/pull is implemented, it automatically uses ~/. SSH /id_rsa for authentication.

Building branch

The master is a stable branch that is generally push-resistant and can only operate on gitLab. So we usually have to create a new branch of development. The commands used in the work are as follows:

Switch branch

git switch <branch-name>
# or
git checkout <branch-name>
Copy the code

Create a new branch based on the current branch

git checkout -b <branch-name>
Copy the code

Branch renaming

# Do not require pre-cut to any branches
git branch -m <old-name> <new-name>
Copy the code

Bind upstream branches

# origin is the default host name that points to the repository URL you specified with Git Clone. You can change origin to something else by doing something else, but don't mess with it for communication purposes
git branch -u origin <remote-branch>
Copy the code

-u is equivalent to –set-upstream-to=.

Push/pull branch

Unbound upstream branch, push/pull code:

git push origin <remote-branch-name>
git pull origin <remote-branch-name>
Copy the code

After the upstream branch is bound, the push/pull code can be abbreviated as:

git push
git pull
Copy the code

The -f parameter is used to force a push, usually on branches that have been rebase (the commit history has been collated, the hash has been changed). You can also add the -u parameter to the first push/pull code, which also binds upstream branches

git push -u origin <remote-branch-name>
git pull -u origin <remote-branch-name>
Copy the code

Temporarily save the status of the staging area

If there is content in the staging area when you pull or switch branches or rebase, this will block the command and prompt you to process the contents of the staging area first. If you want to clean up the trash under the cabinet, you can remove the cabinet first, clean up the trash and then put the cabinet back to its original position. This is what the Stash command does. You can use it to push the staging area onto the stack first and then unstack it.

# push the staging area
git stash
# unstack the staging area
git stash pop
Copy the code

Delete the branch

# delete local branch
git branch -D <branch-name>
# delete remote branch
git push origin :<remote-branch-name>
Copy the code

The operation above to delete the remote branch can be regarded as pushing an empty branch to the associated remote branch, causing the remote branch to be deleted.

Submit code

The actual project code is your workspace. Git also has a staging area. Creating a COMMIT is usually done by adding files from the workspace to the staging area and then creating a commit record from the staging area.

Add to staging area

Add a.testt b.testt c.testt to the staging area
git add A.txt B.txt C.txt
Add all current files to the staging area
git add .
Copy the code

submit

git commit -m "Submit comments" 
View the commit history
git log
Copy the commit of the specified hash after the current branch
git cherry-pick <hash>
Copy the code

Modifying commit History

# merge to previous submission
git commit --amend -m "New submitted comment"Git rebase -i HEAD~<n> git rebase -i HEAD~<n>Copy the code

If you change pick to squash, the commit in this row is merged with the previous commit. If you change pick to squash, the commit in this row is deleted. If you save the commit, the rebase operation starts. If a conflict occurs, merge it, resolve the conflict and add the file to the staging area. Then type git rebase –continue to rebase (never commit git). Git rebase — Abort abort. Git rebase abort causes the hash value of the affected commit and its subsequent commits to change and push it to a remote branch.

If someone needs to pull your code and you push a bunch of rebase files to the remote branch, someone else will be prompted when pulling the code again. If he only needs to pull the code, he can force the remote branch to overwrite the local branch without making any changes to the code

git pull -f origin <remote-branch>:<local-branch>
Copy the code

Version back

One of the most important features of version control is version rollback

Undo changes to the staging area
git reset HEAD
Return to the state of commit-hash and subsequent commit records and the current staging content not being added to the staging area
git reset <commit-hash>
# commit-hash and subsequent commit records are undone and returned to staging
git reset --soft <commit-hash>
# commit-hash and subsequent commit records are destroyed, and the workspace returns to the state before these COMMIT changes occurred
git reset --hard <commit-hash>
Create a new commit that will undo the workspace to the state before the commit-hash occurred
git revert <commit-hash>
Copy the code

Commit to hash alias

What if you don’t want to rehash your git log every time you use commit-hash? For some hashes that have aliases, you can replace the hash with an alias.

• The branch name can represent the latest hash submitted for that branch
• HEAD represents the latest hash submitted by the current branch
• HEAD~1,HEAD~2, · · · · · ·,HEAD~nRepresents the hash committed at the first, second, and NTH end of the current branch

Do not ignore file name case

By default, git tracks file changes without being case-sensitive. Directly renaming files only changes case. Git will not detect this change

git config --global core.ignorecase false
Copy the code

git hooks

In the front-end project’s code base, you will sometimes find that additional commands are executed when submitting and pushing code, which may be implemented by a husky or husky-like NPM library. Husky-git hooks (typicode.github. IO), which are in the “.git/hooks “folder, will be executed when appropriate. If the pre-commit script is executed before the git commit, if you do not want the script to be executed, you can enter the git command with the –no-verify parameter as follows:

git commit --no-verify -m "Feat: New Submission"
Copy the code