General operation of Git

Lao Mao Published 21 minutes ago

As a developer, no matter where he goes, he may have an indescribable relationship with the code warehouse. From clone warehouse = > new function branch = > submit after the development function is completed = > branch merge = > label = > deploy to the online environment, this series of operations are inseparable from the code version management tool Git, So familiar with common commands helps us improve efficiency.

Clone git warehouse

Gitlab or github can be cloned in two ways, ssh protocol and http protocol. To use http, you only need to enter the user name and password. To use ssh, you need to deploy your public key to gitlab or github and configure it in the settings of the login user. Query your own public key, generally the following directory of your computer:

➜  ~ cd .ssh
➜  .ssh ls
id_rsa      id_rsa.pub  known_hosts

The public key is the ID_ After the content in the rsa.pub file is deployed, you can clone the repository.

Branch operation

git checkout -b

OK, it is said that you have cloned the warehouse called Blog locally. Now you want to make a comment function. Generally, entering the project from the terminal is like this:

➜  Blog git:(main)

If the main branch or master is deployed in the production environment, the new functions should be checked out from the main branch.

➜  Blog git:(main) git checkout -b comment
Switched to a new branch 'comment'

* comment
  ele
  main

git status / git add / git commit

Here you can do your functions on this branch. When you write about the rise, suddenly the leader tells you that there is a problem on the line that needs to be repaired urgently. Suddenly a little flustered, but you still have to save half of your comments first. So you use the following command:

➜  Blog git:(comment) ✗ git status
On branch comment
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

// When you see the familiar content changes, you are relieved. Use the following command to incorporate them into version management
➜  Blog git:(comment) ✗ git add .
➜  Blog git:(comment) ✗ git commit -m "comment progress 50%"
[comment 006a55d] comment progress 50%
 1 file changed, 1 insertion(+), 1 deletion(-)

git log / git reset

This is OK, but a submission record is generated. In fact, your modifications can be temporarily saved. Now we reset this submission. To reset, we need to know the previous version number:

➜  Blog git:(comment) git log --oneline

006a55d (HEAD -> comment) comment progress 50%
2bf17f8 (origin/main, origin/HEAD, main) loading
56131ba Optimize style
cc91d8c abstract
a81dbe7 sitemap
b915f65 baidu

You can see that we just need to reset 2bf17f8 this time, but we need to keep the hard-written code (bugs). So he wisely used the following command:

➜  Blog git:(comment) git reset --mixed 2bf17f8
Unstaged changes after reset:
M    README.md
➜  Blog git:(comment) ✗ git status
On branch comment
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README.md

Happily returned to the status before submission. If you use git reset --hard 2bf17f8, congratulations. All previous changes have been lost, so be careful.

git stash

In order to reduce one useless submission, we use git stash to temporarily store incomplete comments:

➜  Blog git:(comment) ✗ git stash
Saved working directory and index state WIP on comment: 2bf17f8 loading
// You can see that the content of this stash is recorded based on the information submitted last time

Then you can handle the urgent tasks arranged by the leader and cut out the hot from the main branch_ Fix branch

➜  Blog git:(main) git checkout -b hot_fix
Switched to a new branch 'hot_fix'

Save and submit after problem repair:

➜  Blog git:(hot_fix) ✗ git add .
➜  Blog git:(hot_fix) ✗ git commit -m "bug fixed"

git merge

Switch branch to main merge hot_fix

➜  Blog git:(hot_fix) git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
➜  Blog git:(main) git merge hot_fix
Updating 2bf17f8..b85e853
Fast-forward
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Here, you can release the new version from the main branch to the online, and fix the urgent problems on the online. At this time, a useless branch hot appears in your local area_ fix:

➜  Blog git:(main) git branch
  comment
  ele
  hot_fix
* main

You can now delete it and use:

➜  Blog git:(main) git branch -d hot_fix
Deleted branch hot_fix (was b85e853).

If you pushed it to a remote before, check all remote branches:

➜  Blog git:(main) git branch -r
  origin/HEAD -> origin/main
  origin/ele
  origin/hot_fix
  origin/main
(END)

Now the remote branch is useless. Use the following command to delete the remote branch:

➜  Blog git:(main) git branch -r -d origin/hot_fix
Deleted remote-tracking branch origin/hot_fix (was b85e853).

Now it's back to the refreshing state. You can go back to the functions before the comment branch is completed:

➜  Blog git:(main) git checkout comment
Switched to branch 'comment'

// Restore previously staged content
➜  Blog git:(comment) git stash pop
On branch comment
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (0553a4fa89f44ea5708a21d5c421c7b1115c40cb)

happy coding again. Through a scenario, this paper reproduces the use of some git commands in practical work, hoping to be helpful to you.