style: 配置站点副标题/Logo/头像并整理图片资源
- 启用首页副标题（打字机效果） - 修复 nav.logo 被 theme_config 空值覆盖导致不显示的问题 - 头像改为 /images/core.jpg - 重做 logo：去白底并圆形内部填白 - 新增 Markdown 使用指南，整理文章图片到对应目录
This commit is contained in:
+56
-56
@@ -1,10 +1,9 @@
|
||||
---
|
||||
---
|
||||
title: Git使用教学
|
||||
date: 2026-07-08 10:00:00
|
||||
tags: [编程, 教学]
|
||||
categories: 教学
|
||||
cover: /img/cover.jpg
|
||||
top_img: /img/top.jpg
|
||||
tags: [编程, 教程]
|
||||
categories: 教程
|
||||
cover: /images/Git使用教学/github.png
|
||||
description: 认识一下Git！
|
||||
---
|
||||
|
||||
@@ -12,11 +11,11 @@ description: 认识一下Git！
|
||||
|
||||
Git是当前最先进、最主流的**分布式**版本控制系统，免费、开源！核心能力就是版本控制。再具体一点，就是面向代码文件的版本控制，代码的任何修改历史都会被记录管理起来，意味着可以恢复到到以前的任意时刻状态。支持跨区域多人协作编辑，是团队项目开发的必备基础，所以Git也就成了程序员的必备技能。
|
||||
|
||||
|
||||
|
||||
|
||||
**🟢主要特点**：
|
||||
|
||||
|
||||
|
||||
|
||||
Git是Linux之父被迫开发的，为了解决Linux混乱的代码管理而开发的。Linux和Git之父 **李纳斯·托沃兹**（Linus Benedic Torvalds），来自1969年的芬兰。
|
||||
|
||||
@@ -50,11 +49,11 @@ Git是Linux之父被迫开发的，为了解决Linux混乱的代码管理而开
|
||||
|
||||
### 工作区/暂存区/仓库
|
||||
|
||||
|
||||
|
||||
|
||||
工作区、暂存区、版本库是Git最基本的概念，关系如下图：
|
||||
|
||||
|
||||
|
||||
|
||||
**🔸工作区**（Workspace）就是在电脑里能看到的代码库目录，是我们搬砖的地方，新增、修改的文件会提交到暂存区。
|
||||
|
||||
@@ -62,7 +61,7 @@ Git是Linux之父被迫开发的，为了解决Linux混乱的代码管理而开
|
||||
|
||||
**🔸版本库/仓库**（Repository /rɪˈpɑːzətɔːri/ 仓库）Git的管理仓库，管理版本的数据库，记录文件/目录状态的地方，所有内容的修改记录（版本）都在这里。就是工作区目录下的隐藏文件夹`.git`，包含暂存区、分支、历史记录等信息。
|
||||
|
||||
|
||||
|
||||
|
||||
如上图，为对应本地仓库目录的结构关系。
|
||||
|
||||
@@ -70,13 +69,13 @@ Git是Linux之父被迫开发的，为了解决Linux混乱的代码管理而开
|
||||
|
||||
Git的工作流程核心就下面几个步骤，掌握了就可以开始写Bug了。
|
||||
|
||||
|
||||
|
||||
|
||||
### Git状态（图）
|
||||
|
||||
Git在执行提交的时候，不是直接将工作区的修改保存到仓库，而是将暂存区域的修改保存到仓库。要提交文件，首先需要把文件加入到暂存区域中。因此，Git管理的文件有三（+2）种状态：
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -97,7 +96,7 @@ git version 2.33.0.windows.2
|
||||
|
||||
Git有三个主要的配置文件：三个配置文件的优先级是**① < ② < ③**
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
#查看git配置
|
||||
@@ -153,7 +152,7 @@ $ cat 'C:\Users\Kwongad\.gitconfig'
|
||||
|
||||
工作目录中的文件并不是全都需要纳入版本管理，如日志、临时文件、私有配置文件等不需要也不能纳入版本管理，那该怎么办呢？
|
||||
|
||||
|
||||
|
||||
|
||||
在工作区根目录下创建“`.gitignore`”文件，文件中配置不需要进行版本管理的文件、文件夹。“`.gitignore`”文件本身是被纳入版本管理的，可以共享。有如下规则：
|
||||
|
||||
@@ -180,27 +179,27 @@ doc/*.txt #会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
|
||||
|
||||
SourceTree的[官网](https://www.sourcetreeapp.com/ "https://www.sourcetreeapp.com/") 下载安装包，支持Window、Mac系统，按照提示完成安装。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### TortoiseGit
|
||||
|
||||
|
||||
|
||||
|
||||
[TortoiseGit](https://tortoisegit.org/ "https://tortoisegit.org/") 官网下载安装包，及中文语言包，按照提示完成安装。小乌龟的Git是集成到操作系统里的，直接右键文件夹就可以进行Git操作了。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### VSCode中的Git
|
||||
|
||||
VSCode自带的Git工具基本已经可以满足日常使用了，既有可视化功能，也能敲命令，习惯了不就不用安装其他GUI工具了。不过还是可以再安装一些VSCode插件，来增强Git功能。
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -229,7 +228,7 @@ Initialized empty Git repository in D:/Project_Files/github.Kwong/KwebNote/.git/
|
||||
|
||||
创建完多出了一个被隐藏的`.git`目录，这就是本地仓库Git的工作场所。
|
||||
|
||||
|
||||
|
||||
|
||||
克隆远程仓库，如在github上创建的仓库“`https://github.com/kwonganding/KWebNote.git`”
|
||||
|
||||
@@ -246,7 +245,7 @@ Resolving deltas: 100% (48/48), done.
|
||||
|
||||
会在当前目录下创建“KWebNote”项目目录。
|
||||
|
||||
|
||||
|
||||
|
||||
### 暂存区add
|
||||
|
||||
@@ -275,11 +274,11 @@ $ git mv [file-original] [file-renamed]
|
||||
|
||||
修改文件“R.md”，未暂存：
|
||||
|
||||
|
||||
|
||||
|
||||
执行`git add .`暂存：
|
||||
|
||||
|
||||
|
||||
|
||||
### 提交commit-记录
|
||||
|
||||
@@ -287,11 +286,11 @@ $ git mv [file-original] [file-renamed]
|
||||
|
||||
多个提交就形成了一条时间线，每次提交完，会移动当前分支`master`、`HEAD`的“指针”位置。
|
||||
|
||||
|
||||
|
||||
|
||||
Sourcetree上的历史记录：
|
||||
|
||||
|
||||
|
||||
|
||||
> 📢一般情况，每完成一个小功能、一个Bu就可以提交一次，这样会形成比较清晰的历史记录。
|
||||
|
||||
@@ -311,7 +310,7 @@ Sourcetree上的历史记录：
|
||||
| git **reflog** | 查看所有可用的历史版本记录（实际是HEAD变更记录），包含被回退的记录（**重要**） |
|
||||
| git status | 查看本地仓库状态，比较常用的指令，加参数`-s`简洁模式 |
|
||||
|
||||
|
||||
|
||||
|
||||
通过`git log`指令可以查看提交记录日志，可以很方便的查看每次提交修改了哪些文件，改了哪些内容，从而进行恢复等操作。
|
||||
|
||||
@@ -347,7 +346,7 @@ $ git log -n2 --oneline
|
||||
|
||||
Git中最重要的就是提交记录了，其他如**标签**、**分支**、**HEAD** 都对提交记录的“指针”引用，指向这些提交记录，理解这一点很重要。
|
||||
|
||||
|
||||
|
||||
|
||||
上图中：
|
||||
|
||||
@@ -416,7 +415,7 @@ d3e15f9 HEAD@{9}: reset: moving to HEAD~
|
||||
|
||||
☘️画个图更清晰些：
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
# 查看文件的修改
|
||||
@@ -435,7 +434,7 @@ $ git diff --shortstat "@{0 day ago}"
|
||||
|
||||
Git作为分布式的版本管理系统，每个终端都有自己的Git仓库。但团队协作还需一个中间仓库，作为中心，同步各个仓库。于是服务端（远程）仓库就来承担这个职责，服务端不仅有仓库，还配套相关管理功能。
|
||||
|
||||
|
||||
|
||||
|
||||
可以用公共的Git服务器，也可以自己搭建一套Git服务器。
|
||||
|
||||
@@ -443,7 +442,7 @@ Git作为分布式的版本管理系统，每个终端都有自己的Git仓库
|
||||
|
||||
Git服务器一般提供两种登录验证方式：
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
#查看当前远程仓库使用的那种协议连接：
|
||||
@@ -459,7 +458,7 @@ git config --global http.sslVerify false
|
||||
|
||||
基于HTTPS的地址连接远程仓库，Github的共有仓库克隆、拉取（pull）是不需要验证的。
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
$ git clone 'https://github.com/kwonganding/KWebNote.git'
|
||||
@@ -493,19 +492,19 @@ https://kwonganding:[加密内容付费可见]@github.com
|
||||
|
||||
### 🔑远程用户登录：SSH
|
||||
|
||||
|
||||
|
||||
|
||||
SSH（Secure Shell，安全外壳）是一种网络安全协议，通过加密和认证机制实现安全的访问和文件传输等业务，多用来进行远程登录、数据传输。SSH通过公钥、私钥非对称加密数据，所以SSH需要生成一个公私钥对，公钥放服务器上，私有自己留着进行认证。
|
||||
|
||||
|
||||
|
||||
|
||||
**① 生成公私钥**：通过Git指令`ssh-keygen -t rsa`生成公私钥，一路回车即可完成。生成在“`C:\Users\用户名\.ssh`”目录下，文件`id_rsa.pub`的内容就是公钥。
|
||||
|
||||
|
||||
|
||||
|
||||
**② 配置公钥**：打开`id_rsa.pub`文件，复制内容。Github上，打开`Setting`➤ `SSH and GPG keys` ➤ `SSH keys` ➤ 按钮`New SSH key`，标题（Title）随意，秘钥内容粘贴进去即可。
|
||||
|
||||
|
||||
|
||||
|
||||
SSH配置完后，可用`ssh -T git@github.com`来检测是否连接成功。
|
||||
|
||||
@@ -542,7 +541,7 @@ Hi kwonganding! You've successfully authenticated, but GitHub does not provide s
|
||||
|
||||
**🔸拉取**（pull）：从服务端（远程）仓库更新到本地仓库。
|
||||
|
||||
|
||||
|
||||
|
||||
### fetch与pull有什么不同？
|
||||
|
||||
@@ -550,7 +549,7 @@ Hi kwonganding! You've successfully authenticated, but GitHub does not provide s
|
||||
|
||||
> `git pull` = `git fetch` + `git merge`
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
# fetch只更新版本库
|
||||
@@ -577,13 +576,13 @@ Fast-forward
|
||||
|
||||
分支是从主线分离出去的“副本”，分支就像是平行宇宙，可独立发展，独立编辑、提交，也可以和其他分支合并。分支是Git的核心必杀利器之一，分支创建、切换、删除都非常快，他非常的轻量。所以，早建分支！多用分支！
|
||||
|
||||
|
||||
|
||||
|
||||
### 分支Branch
|
||||
|
||||
比如有一个项目团队，准备10月份发布新版本，要新开发一堆黑科技功能，占领市场。你和小伙伴“小美”一起负责开发一个新功能A，开发周期2周，在这两周你们的代码不能影响其他人，不影响主分支。这个时候就可以为这个新功能创建一个分支，你们两在这个分支上干活，2周后代码开发完了、测试通过，就可以合并进要发版的开发分支了。安全、高效，不影响其他人工作，完美！
|
||||
|
||||
|
||||
|
||||
|
||||
在实际项目中，一般会建几个主线分支。
|
||||
|
||||
@@ -635,7 +634,7 @@ $ git branch
|
||||
|
||||
代码仓库可以有多个分支，`master`为默认的主分支，但只有一个分支在工作状态。所以要操作不同分支，需要切换到该分支，`HEAD`就是指向当前正在活动的分支。
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
# 切换到dev分支，HEAD指向了dev
|
||||
@@ -656,13 +655,13 @@ ref: refs/heads/dev
|
||||
|
||||
把两个分支的修改内容合并到一起，常用的合并指令`git merge [branch]`，将分支`[branch]`合并到当前分支。根据要合并的内容的不同，具体合并过程就会有多种情况。
|
||||
|
||||
|
||||
|
||||
|
||||
### 🔸快速合并（Fast forward）
|
||||
|
||||
如下图，`master`分支么有任何提交，“`git merge dev`”合并分支`dev`到`master`，此时合并速度就非常快，直接移动`master`的“指针”引用到`dev`即可。这就是快速合并（Fast forward），不会产生新的提交。
|
||||
|
||||
|
||||
|
||||
|
||||
> **📢强制不用快速合并**：`git merge --no-ff -m "merge with no-ff" dev`，参数`--no-ff`不启用快速合并，会产生一个新的合并提交记录。
|
||||
|
||||
@@ -670,7 +669,7 @@ ref: refs/heads/dev
|
||||
|
||||
如果`master`有变更，存在分支交叉，则会把两边的变更合并成一个提交。
|
||||
|
||||
|
||||
|
||||
|
||||
上图中，创建`dev`分支后，两个分支都有修改提交，因此两个分支就不在一条顺序线上了，此时合并`dev`到`master`就得把他们的修改进行合并操作了。
|
||||
|
||||
@@ -678,13 +677,13 @@ ref: refs/heads/dev
|
||||
|
||||
在有冲突的文件中，`<<<<<<< HEAD`开头的内容就表示是有冲突的部分，需要人工处理，可以借助一些第三方的对比工具。人工处理完毕后，完成合并提交，才最终完成此次合并。`=======`分割线上方是当前分支的内容，下方是被合并分支的变更内容。
|
||||
|
||||
|
||||
|
||||
|
||||
### 变基rebase
|
||||
|
||||
把两个分支的修改内容合并到一起的办法有两种：`merge` 和 `rebase`，作用都是一样的，区别是`rebase`的提交历史更简洁，干掉了分叉，merge的提交历史更完整。
|
||||
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
$ git rebase master
|
||||
@@ -702,7 +701,7 @@ $ git merge dev
|
||||
|
||||
默认标签是打在最新提交的commit上的，如果希望在指定的提交上打标签则带上提交编号（commit id）：`git tag v0.9 f52c633`
|
||||
|
||||
|
||||
|
||||
|
||||
| **指令** | **描述** |
|
||||
| --- | --- |
|
||||
@@ -738,7 +737,7 @@ v1
|
||||
|
||||
发现写错了要回退怎么办？看看下面几种后悔指令吧！
|
||||
|
||||
|
||||
|
||||
|
||||
### 后悔指令🔥
|
||||
|
||||
@@ -775,11 +774,11 @@ Updated 1 path from f951a96
|
||||
|
||||
如下图：
|
||||
|
||||
|
||||
|
||||
|
||||
`reset`有三种模式，对应三种参数：`mixed`（默认模式）、`soft`、`hard`。三种参数的主要区别就是对工作区、暂存区的操作不同。
|
||||
|
||||
|
||||
|
||||
|
||||
| **模式名称\\** | **描述** | **HEAD的位置** | **暂存区** | **工作区** |
|
||||
| --- | --- | --- | --- | --- |
|
||||
@@ -818,7 +817,7 @@ ccb9937 (HEAD -> main, origin/main, origin/HEAD) HEAD@{0}: commit: 报表新增
|
||||
|
||||
安全的撤销某一个提交记录，基本原理就是生产一个新的提交，用原提交的逆向操作来完成撤销操作。注意，这不同于`reset`，`reset`是回退版本，revert只是用于撤销某一次历史提交，操作是比较安全的。
|
||||
|
||||
|
||||
|
||||
|
||||
如上图：
|
||||
|
||||
@@ -849,19 +848,19 @@ $ git revert 41ea42 -m'撤销对***的修改'
|
||||
|
||||
Git flow（Git工作流程）是指软件项目中的一种Git分支管理模型，经过了大量的实践和优化，被认为是现代敏捷软件开发和DevOps（开发、技术运营和质量保障三者的交集）的最佳实践。Git flow主要流程及关键分支：[原图地址-processon](https://www.processon.com/view/59ec836de4b0c86d400e99f1?fromnew=1 "https://www.processon.com/view/59ec836de4b0c86d400e99f1?fromnew=1")
|
||||
|
||||
|
||||
|
||||
|
||||
**✅主分支：master**，稳定版本代码分支，对外可以随时编译发布的分支，不允许直接Push代码，只能请求合并（pull request），且只接受`hotfix`、`release`分支的代码合并。
|
||||
|
||||
**✅热修复分支：hotfix**，针对线上紧急问题、bug修复的代码分支，修复完后合并到主分支、开发分支。
|
||||
|
||||
|
||||
|
||||
|
||||
**✅发版分支：release**，版本发布分支，用于迭代版本发布。迭代开发完成后，合并`dev`代码到`release`，在`release`分支上编译发布版本，以及修改bug（定时同步bug修改到`dev`分支）。测试完成后此版本可以作为发版使用，然后把稳定的代码push到`master`分支，并打上版本标签。
|
||||
|
||||
**✅开发分支：dev**，开发版本分支，针对迭代任务开发的分支，日常开发原则上都在此分支上面，迭代完成后合并到release分支，开发、发版两不误。
|
||||
|
||||
|
||||
|
||||
|
||||
**✅其他开发分支：dev-xxx**，开发人员可以针对模块自己创建本地分支，开发完成后合并到dev开发分支，然后删除本地分支。
|
||||
|
||||
@@ -911,7 +910,7 @@ $ git stash pop
|
||||
|
||||
当有一个紧急bug，在`dev`上修复完，我们需要把`dev`上的这个bug修复所做的修改“复制”到`master`分支，但不想把整个dev合并过去。为了方便操作，Git专门提供了一个`cherry-pick`命令，让我们能复制一个特定的提交到当前分支，而不管这个提交在哪个分支。
|
||||
|
||||
|
||||
|
||||
|
||||
如上图，操作过程相当于将该提交导出为补丁文件，然后在当前`HEAD`上重放，形成无论内容还是提交说明都一致的提交。
|
||||
|
||||
@@ -921,3 +920,4 @@ $ git cherry-pick [commit]
|
||||
```
|
||||
|
||||
---
|
||||
原文链接 ：https://juejin.cn/post/7195030726096453690
|
||||
Reference in New Issue
Block a user