Git basic common commands and summary

Git basic common commands and summary

1. Create a repository

# 初始化版本库（随后文件夹会生成一个.git的文件夹，是git的版本库）
git init

# 初始化git信息
git config --global user.name '用户名'
git config --global user.email '邮箱地址'

2. Working area and temporary storage area

The Git control system is divided into two concepts: work area and temporary storage area. The workspace is the local folder created by this project. After using gitthe command , the workspace will .gitgenerate a folder containing many things, the most important of which is the temporary storage area stagecalled . There is the first branch that Git automatically created for us master, and a pointer masterto it called HEAD.

When we add files to the Git repository, we do it in two steps:

​ Step 1: Use git addthe command to add the file modification to the temporary storage area;

​ Step 2: Use git committhe command to submit all the contents of the temporary storage area to the current branch.

3. Add and submit files

# 将readme.txt文件添加到暂存区
git add readme.txt
# 将所有的文件添加到暂存区
git add . 

# 将暂存区的所有文件提交到本地版本库中
git commit -m '提交时的备注'

4. Undo the modification

# 查看当前状态
git status

$ git status
On branch master
# 还未添加到暂存区时的状态
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.txt
        
$ git status
# 添加到暂存区后的状态（待提交）
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   readme.txt


# 撤销工作区的修改
# 比如：在readme.txt文件中，修改了某些内容，但还未将文件添加到暂存区中，若此时想放弃本次修改的内容，则使用以下命令即可放弃修改，readme.txt文件中的内容就会恢复到修改内容之前
git checkout -- readme.txt 
或 
git restore readme.txt （新版本Git，建议使用）

# 撤销暂存区的修改
# 比如：在readme.txt文件中，修改了某些内容，并且将文件添加到了暂存区中，若此时想放弃本次添加到暂存区中的文件，则使用以下命令即可放弃添加，暂存区会恢复到添加文件之前
git reset HEAD readme.txt
或 
git restore --staged readme.txt（新版本Git，建议使用）

5. Delete files

# 1.本地删除readme.txt文件
rm -f readme.txt

# 2.将删除的文件提交到暂存区
git add readme.txt
或
git rm readme.txt

# 3.提交到本地仓库
git commit -m '删除readme.txt文件'

# 若本地误删除某个文件，但未提交到本地版本库，则可以使用上节所述的撤销修改命令来恢复文件（删除文件本身也是一种修改）
git restore 文件名
git restore --staged 文件名

6. Version rollback

# 查看提交的日志
git log 

$ git log
# 下面的字符串表示提交的版本号
commit 45655a0a6041eaf6190f6c279b81096f9bef04f9 (HEAD -> master) 
Author: 别回头丶 <[email protected]>
Date:   Wed Jan 12 14:02:12 2022 +0800

    第二次提交

commit 121d79b208a791180b621cc14da33c32c6ef0244
Author: 别回头丶 <[email protected]>
Date:   Wed Jan 12 13:15:11 2022 +0800

    第一次提交
    
# 以图表的方式展示日志
git log --graph

$ git log --graph
* commit 45655a0a6041eaf6190f6c279b81096f9bef04f9 (HEAD -> master) 
| Author: 别回头丶 <[email protected]>
| Date:   Wed Jan 12 14:02:12 2022 +0800
|
|     第二次提交
|
* commit 121d79b208a791180b621cc14da33c32c6ef0244
| Author: 别回头丶 <[email protected]>
| Date:   Wed Jan 12 13:15:11 2022 +0800
|
|     第一次提交

# 查看操作日志
git reflog

$ git reflog
# 首位的字符串表示版本号（版本号的前几位）
45655a0 (HEAD -> master) HEAD@{
    
    0}: commit: 第二次提交
121d79b HEAD@{
    
    1}: commit (initial): 第一次提交
  
 
# 版本回退
# 首先，要进行版本回退，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新一次的
# 提交45655a0...，而上一个版本就是HEAD^，上上一个版本就是HEAD^^，往上100个版本写100个^比较容易写不
# 过来，所以写成HEAD~100。

git reset --hard 指定的版本(使用HEAD或者版本ID)

# 回退到上一个版本
git reset --hard HEAD^

# 回退到指定的版本
git reset --hard 45655a0

Seven, remote warehouse

# 本地版本库关联远程版本库
git remote add origin https://gitee.com/LLS312885991/test.git

# 将本地仓库中的当前分支推送到远程仓库中所对应的分支
# 若多人协作时，有其他开发者先于自己push到了远程仓库，则自己先要pull拉取最新的提交，并且在本地合并之
# 后，才能push成功
git push
git push origin master
git push origin dev

# 由于远程仓库是空的，所以我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推# 送到远程新的master分支上，还会把本地的master分支和远程的master分支关联起来，这样在以后的推送或者拉
# 取时就可以简化命令，直接使用 git push 或者 git pull
git push -u origin master

# 拉取远程仓库的代码同步到本地仓库
git pull

# 查看关联的远程仓库信息
git remote -v

$ git remote -v
origin  https://gitee.com/LLS312885991/test.git (fetch)
origin  https://gitee.com/LLS312885991/test.git (push)

# 解除本地仓库与远程仓库的关联绑定
git remote rm origin

# 克隆远程仓库到本地
git clone https://gitee.com/LLS312885991/test.git

8. Branch management

The role of branch is very powerful, it makes everyone have their own independent development space when multiple people work and develop without interfering with each other. Generally, when multiple people develop, each person will first create their own branch, and then develop. After the development is completed, merge it into the main branch, and finally delete their own branch.

# 创建分支
git branch 分支名称
git branch dev

# 查看所有分支（*代表当前分支）
git branch

$ git branch
  dev
* master

# 切换到dev分支
git switch dev

$ git switch dev
Switched to branch 'dev'

# 创建并切换到dev分支
git switch -c dev

$ git switch -c dev
Switched to a new branch 'dev'

# 将dev分支上的内容合并到当前分支（此命令只能简单合并，即两个分支上所修改的内容无冲突）
git merge dev

# 删除dev分支
git branch -d dev

# 合并冲突（即两个分支上修改同一个文件，且修改的内容不一致时，会出现合并冲突，此时需要手动解决冲突）
$ git merge dev
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt # 显示合并冲突，且告知是在a.txt文件中有冲突
Automatic merge failed; fix conflicts and then commit the result.

$ cat a.txt 
<<<<<<< HEAD # 显示的是当前分支上，a.txt中修改的内容
hello world! liulusheng
=======
hello world! dev # 显示的是dev分支上，a.txt中修改的内容
>>>>>>> dev

$ vim a.txt
hello world! liulusheng # 手动解决冲突，修改为需要保留的内容

$ git add a.txt # 再添加该文件到暂存区

$ git commit -m '合并冲突' # 再提交该文件到版本库即可
[master ceeba28] 合并冲突

# 使用git log也可以查看合并情况，--graph表示以图表的方式展示
git log --graph

$ git log --graph
*   commit ceeba28f86befa755d72d61155e3a4bb95d04bb3 (HEAD -> master, origin/master)
|\  Merge: f74d466 6aaee45
| | Author: 别回头丶 <[email protected]>
| | Date:   Wed Jan 12 18:29:17 2022 +0800
| |
| |     合并冲突
| |
| * commit 6aaee45e1e0838a0f8b9a1d0ab368dddf030e41e (dev)
| | Author: 别回头丶 <[email protected]>
| | Date:   Wed Jan 12 18:22:19 2022 +0800
| |
| |     dev分支上修改a.txt
| |
* | commit f74d4662153a4a665e638352df528c3c9cb3bdbd
|/  Author: 别回头丶 <[email protected]>
|   Date:   Wed Jan 12 18:21:49 2022 +0800
|
|       master分支上修改a.txt
|

Notice: When Git cannot automatically merge branches, it must first resolve the conflict. After resolving conflicts, submit again and the merge is complete. And to resolve the conflict is to manually edit the file that failed to merge with Git to the content we want, and then submit it.

Nine, BUG branch

In software development, BUG is like common food. If there is a BUG, ​​it needs to be fixed, and in Git, because the branch is so powerful, each BUG can be fixed through a new temporary branch, after the repair, the branch is merged, and then the temporary branch is deleted.

But when you get a task to fix a bug in codename 101, naturally, you want to create a branch issue-101to fix it, but wait, the work that is currently being done devon has not been committed, not because you don't want to commit, but The problem is that the work is only halfway through and cannot be submitted yet. It is estimated that it will take 1 day to complete. However, the BUG must be fixed within two hours, what should I do?

Fortunately, Git also provides a stashfunction that can "store" the current work site, and then restore the site to continue working after the BUG is resolved.

# 比如，新建了一个b.txt文件，并且添加到了暂存区，但未提交到版本库中。查看此时状态
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   b.txt

# 将当前分支上的工作现场储存起来
git stash

# 再查看状态
$ git status
On branch master
nothing to commit, working tree clean

# 查看所有stash工作现场
git stash list

$ git stash list
stash@{
    
    0}: WIP on master: 76f2c95 合并冲突
stash@{
    
    1}: WIP on master: 76f2c95 合并冲突

# 恢复最近一次的工作现场
git stash apply (恢复现场，但恢复后，stash的内容不会删除，需要手动删除)
$ git stash apply
On branch dev
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   b.txt

git stash pop (恢复现场，并且会删除对应的stash内容)
$ git stash pop
On branch dev
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   b.txt

Dropped refs/stash@{
    
    0} (f89d3263c666988318456ba3a0676213920af788)

# 恢复指定的工作现场
git stash apply stash@{
    
    1}

# 删除最近一次的工作现场
git stash drop

# 删除指定的工作现场
git stash drop stash@{
    
    1}

10. Tag management

When releasing a version, we usually put a tag (tag) in the repository first, so that the version at the moment of tagging is uniquely determined. Whenever in the future, fetching a tagged version is to fetch the historical version at the moment of tagging. So, a tag is also a snapshot of the repository. 标签In fact, it corresponds to a certain one commit id, and it can be understood 标签和版本号that is equivalent to 域名和IPthe relationship of .

# 在当前分支上创建标签（标签默认是打在最新提交的commit上）
git tag 标签名称
git tag v1.0

# 在指定commit上创建标签
git tag 标签名称 提交ID
git tag  v2.0  45655a0

# 创建带说明信息的标签
git tag -a 标签名称 -m 说明信息 

# 查看当前分支上的所有标签
git tag

# 查看对应的标签信息
git show 标签名称
git show  v1.0

# 删除对应的标签
git tag -d 标签名称
git tag -d  v1.0

# 推送指定的标签到远程仓库
git push origin 标签名称
git push origin v1.0

$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.2]
To https://gitee.com/LLS312885991/test.git
 * [new tag]         v1.0 -> v1.0

# 一次性推送全部尚未推送到远程的本地标签
git push origin --tags

# 删除远程仓库的标签
# 1. 先删除本地仓库的标签
git tag -d v1.0

# 2. 再从远程仓库中删除
git push origin :refs/tags/v1.0