Git 本地仓库完全指南：从安装到版本穿梭
📝 前言
提到 版本控制，很多人的第一反应是"听不懂，但又好像很重要"。
其实你可能早就用过了——只是没意识到。比如你写论文的时候，是不是经常这样命名文件：毕业论文v1.docx、毕业论文v2_导师修改版.docx、毕业论文_终版不要改.docx、毕业论文_这次真的终版.docx、毕业论文_打死也不再改.docx……
每次改完都要 Ctrl+C、Ctrl+V 复制一份新文件，文件越来越多，多到最后自己都搞不清哪个版本改了什么。这还只是你一个人写，要是 5 个人一起协作写一个项目呢？文件传来传去，版本混乱、合并冲突、改动丢失——这些场景在程序员的世界里，每天都在上演。
🎯 本节目标：带你彻底搞懂 Git 是什么、为什么需要版本控制器、怎么在自己的电脑上装上 Git，并完成从 创建本地仓库 → 添加文件 → 修改/删除文件 → 版本回退 → 撤销修改 的全流程实操。学完之后，你不仅能熟练使用 Git 管理自己的代码，更能为下一篇的"分支管理"打下坚实基础。
通过本文，你将掌握：
| 技能 | 应用场景 |
|---|---|
| 理解 Git 与版本控制器的本质 | 面试必问，转岗必备 |
| 在 Windows/Linux/macOS 三平台安装 Git | 任何开发环境都跑得起来 |
| 认识工作区、暂存区、版本库三大核心区域 | 理解 Git 底层原理的关键 |
| 熟练使用 add / commit / log / status / diff | 日常开发的 80% 操作 |
| 玩转 reset / reflog / checkout 三大版本穿梭神器 | 误删误改、版本回退都不慌 |
📌 前置知识： 会基础命令行操作（
cd、ls、mkdir这类），有一台能联网的电脑，零 Git 基础也可以跟上。本系列所有命令都在user@localhost的虚拟环境下演示，复制粘贴前记得改成自己的环境。
文章目录
一、🔍 Git 究竟是个什么东西
1.1 什么是版本控制器
在正式聊 Git 之前，我们先搞清楚版本控制器这个概念。
💡 一句话解释：版本控制器就是一个能记录文件每一次改动、让你随时回溯到任意历史版本的系统。
想象一下，你在写一份超长报告。每次改完都 Ctrl+S，但万一改错了想恢复昨天的版本？传统的做法是手动复制备份，但备份多了你也记不清哪个是哪个。版本控制器就是来解决这个问题的——它会自动帮你记录每一次"保存"，并且支持随时回退、对比、合并。
版本控制器的发展经历了三个阶段：
| 阶段 | 名称 | 特点 | 缺点 |
|---|---|---|---|
| 第一代 | 本地版本控制 | 在自己电脑上用软件记录版本（RCS） | 无法多人协作 |
| 第二代 | 集中式版本控制 | 有一台中央服务器存所有版本（SVN、CVS） | 服务器挂了 = 全部完蛋 |
| 第三代 | 分布式版本控制 | 每个人电脑都有完整版本库（Git） | 学习曲线略陡 |
我们今天要学的 Git，就是当前最主流的分布式版本控制系统。
1.2 Git 的核心特点
Git 之所以能成为行业标准，靠的是这几个"硬核"特性：
① 分布式
这是 Git 最大的特点。没有中央服务器的概念，每个人本地都是完整版本库。这意味着：
- 没有网络也能提交、查看历史、回退版本
- 某台电脑坏了，从其他人的本地就能完整恢复
- 真正的"去中心化"设计
② 高效的存储和性能
Git 用了一种叫 “快照流” 的存储方式，每次提交记录的是文件的快照（而不是差异）。这让它在大型项目里依然飞快——Linus Torvalds（Linux 之父）最初开发 Git 就是为了管理 Linux 内核（千万行代码级别）。
③ 强大的分支支持
Git 的分支操作几乎"零成本"——创建、切换、合并分支在毫秒级完成。这也是为什么后续我们要专门用一整篇博客讲分支管理。
④ 完整性保证
Git 内部用 SHA-1 哈希算法对所有文件内容计算校验和，任何文件被篡改都能立刻发现。
⚠️ 小贴士：Git 只能跟踪"文本文件"的改动，对于图片、视频、Word 这类二进制文件，Git 也能管理，但只能记录大小变化，无法记录具体改了什么。
1.3 你需要理解的基础概念
在动手操作前，先把几个"行话"装进脑子里：
- 仓库（Repository）：通俗说就是你的项目文件夹，被 Git 接管后就叫仓库。Git 通过这个文件夹里的隐藏目录
.git来追踪一切。 - 工作区（Working Directory）：你实际看到的、能编辑文件的目录。
- 暂存区（Stage / Index）：一个临时存放区域，介于工作区和版本库之间。你可以理解为"购物车"——把想提交的文件先放进来，确认无误再"结账"。
- 版本库（Repository）：Git 用来保存项目历史记录和元信息的地方，通常就是
.git这个隐藏目录。 - 提交（Commit）：把暂存区的内容正式保存到版本库，形成一个"历史快照"。
- 分支（Branch）：在主线之外开辟的独立开发线，互不干扰。后
下面这张图概括了这些核心概念之间的关系：
面会专门讲。
1.4 Git ≠ GitHub
很多人会把这两个搞混，必须澄清一下：
- Git：一个软件，装在你电脑上，负责版本控制
- GitHub：一个网站，提供 Git 仓库的远程托管服务（类似网盘）
类比一下：Git 是"记账本"，GitHub 是"线上账本存储平台"。还有 Gitee（码云）、GitLab、Bitbucket 等类似平台。
💡 本篇只讲本地操作，不涉及 GitHub。下一篇讲远程操作时再带大家一起玩 GitHub/Gitee。
二、🛠️ 三平台安装 Git
工欲善其事，必先利其器。Git 的安装在不同系统下略有差异，我们分别来看。
2.1 Windows 平台安装
第一步：下载安装包
去 Git 官网（https://git-scm.com/download/win）下载对应你系统的安装包。如果官网下载慢，也可以用国内的镜像源。
第二步：双击安装
一路 Next 即可，但要留意几个关键选项：
- Select Components：默认全选，保持默认
- Choosing the default editor used by Git：默认是 Vim，但 Vim 对新手不友好。建议改成 VS Code（前提是你装了 VS Code）
- Adjusting your PATH environment：选
Git from the command line and also from 3rd-party software（推荐） - Choosing HTTPS transport backend：选
Use the OpenSSL library - Configuring the line ending conversions：选
Checkout Windows-style, commit Unix-style line endings（避免跨平台换行符问题）
第三步：验证安装
打开 Git Bash（开始菜单里搜 Git Bash），输入：
git --version
看到类似 git version 2.42.0.windows.1 的输出就说明装好了。
⚠️ 注意：在公司或学校电脑上装软件可能没管理员权限，这时候推荐用 Scoop 或 Chocolatey 包管理器安装，或者用便携版 Git。
2.2 macOS 平台安装
macOS 用户有福了，最推荐用 Homebrew：
# 1. 没装 Homebrew 的话先装
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# 2. 一行命令装 Git
brew install git
如果不想用 Homebrew，也可以：
- 从官网下载
.dmg安装包：https://git-scm.com/download/mac - 或者装 Xcode Command Line Tools：
xcode-select --install（会顺带装上 Git，但版本可能偏旧）
验证安装：
git --version
2.3 Linux 平台安装
CentOS / RedHat 系列：
# 先试一下系统里有没有
git --version
# 如果提示 command not found，就装一下
sudo yum install -y git
Ubuntu / Debian 系列：
sudo apt-get install -y git
Arch Linux：
sudo pacman -S git
💡 Linux 发行版自带的 Git 版本可能不是最新的，如果要最新版，建议从源码编译或者用 PPA 源。
2.4 安装后的首次配置
装好 Git 后，第一件事就是配置你的用户名和邮箱。这两步配置非常重要，因为 Git 每次提交都会记录是谁提交的：
# 配置全局用户名（替换成你的名字）
git config --global user.name "Your Name"
# 配置全局邮箱（替换成你的邮箱）
git config --global user.email "your.email@example.com"
💡
--global表示全局配置，这台机器上所有 Git 仓库都会用这个身份。如果你想在某个项目里用不同身份，可以进到那个项目目录里，不加--global再配一次，会覆盖全局配置。
查看所有配置：
git config --list
删除某个配置项：
git config --global --unset user.name
git config --global --unset user.email
⚠️ 别用真实的邮箱！如果你不想被爬虫骚扰，可以去 https://github.com/settings/emails 申请一个 GitHub 提供的隐私邮箱（格式是
ID+username@users.noreply.github.com）。
三、🏗️ 创建你的第一个 Git 本地仓库
Git 装好了，配置也好了，是时候上手实战了。
3.1 什么是"仓库"
💡 仓库（Repository）本质上就是一个目录，只不过这个目录被 Git "接管"了。Git 会在这个目录下创建一个隐藏的
.git文件夹，用来追踪所有文件的改动。
要使用 Git 管理代码，第一步就是创建仓库。
3.2 创建本地仓库
Git 提供了 git init 命令来初始化一个本地仓库：
# 1. 先创建一个项目目录
mkdir /home/user/test/my-first-repo
cd /home/user/test/my-first-repo
# 2. 在该目录下执行 git init
git init
执行成功后，你会看到类似这样的输出：
Initialized empty Git repository in /home/user/test/my-first-repo/.git/
⚠️
git init命令必须在你想变成仓库的那个目录里执行，不然会创建到错误的地方。
.git 目录里有什么？
# 用 tree 命令看一下（Linux/macOS）
tree -a .git
# Windows PowerShell 可以用
Get-ChildItem -Force .git
你会看到类似这样的结构：
.git/
├── branches
├── config
├── description
├── HEAD
├── hooks/
│ ├── applypatch-msg.sample
│ ├── commit-msg.sample
│ └── ... (其他钩子脚本)
├── info/
│ └── exclude
├── objects/
│ ├── info/
│ └── pack/
└── refs/
├── heads/
└── tags/
⚠️ 千万不要手动修改
.git里的任何文件！改坏了你的仓库就废了。Git 会自动管理这些文件。
3.3 认识工作区、暂存区、版本库
这是 **理解 Git 原
────────┘
**工作区（Working Directory）**：你实际看到的、能用编辑器改文件的那个目录。
**暂存区（Stage/Index）**：可以理解为"准备区"。用 `git add` 把工作区的改动放进暂存区。用 `git status` 能看到暂存区里有什么。
**版本库（Repository）**：`.git` 这个隐藏目录。用 `git commit` 把暂存区的内容真正写入版本库，形成一个历史快照。
> <font color="#9B59B6">💡 三区关系：工作区 → add → 暂存区 → commit → 版本库。理解了这个流程，你就理解了 Git 80% 的工作原理。</font>
---
## 四、📝 添加文件：场景一
理论讲完了，现在动手干。
### 4.1 创建并提交第一个文件
**第一步：在工作区创建一个文件**
```bash
# 进入你的仓库目录
cd /home/user/test/my-first-repo
# 创建一个 ReadMe 文件
touch ReadMe
# 写点内容进去（用 echo 或 vim 都行）
echo "hello git" > ReadMe
echo "这是我的第一个 Git 仓库" >> ReadMe
第二步：用 git add 添加到暂存区
git add ReadMe
💡
git add是把文件从工作区"放到购物车"（暂存区），并不是真的提交。
第三步：用 git commit 正式提交
git commit -m "添加 ReadMe 文件"
-m 后面跟着的是提交说明，用来描述这次提交做了什么。绝对不能省略，良好的提交习惯是程序员的基本素养。
执行成功后你会看到：
[master (root-commit) abc1234] 添加 ReadMe 文件
1 file changed, 2 insertions(+)
create mode 100644 ReadMe
这段输出告诉你：
- 这是 master 分支上的根提交（第一次提交）
- commit id 是
abc1234...（SHA-1 哈希值） - 1 个文件被改动，新增了 2 行
4.2 一次添加多个文件
Git 允许你把多个改动一次性提交。多次 add，一次 commit：
# 创建多个空文件
touch file1 file2 file3
# 分别 add 到暂存区
git add file1
git add file2
git add file3
# 一次 commit
git commit -m "添加 3 个空文件"
你会看到输出：
[master def5678] 添加 3 个空文件
3 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file1
create mode 100644 file2
create mode 100644 file3
💡 “多次 add 不同的文件，而只 commit 一次” 是 Git 的标准工作流。原因是：所有需要提交的文件都先 add 到暂存区，commit 时 Git 会把暂存区里所有的改动一次性写入版本库。
4.3 git add 的几种常用姿势
git add 不止 git add 文件名 这一种用法：
# 添加指定文件
git add file1 file2
# 添加指定目录（包括子目录）
git add ./src/
# 添加当前目录所有改动（最常用）
git add .
4.4 查看提交历史：git log
提交了几次之后，怎么看历史记录呢？
git log
输出类似：
commit def5678901234567890abcdef1234567890abcdef (HEAD -> master)
Author: Your Name <your.email@example.com>
Date: Thu Jun 25 15:30:00 2026 +0800
添加 3 个空文件
commit abc1234567890abcdef1234567890abcdef123456
Author: Your Name <your.email@example.com>
Date: Thu Jun 25 15:25:00 2026 +0800
添加 ReadMe 文件
嫌输出太多？加 --pretty=oneline 参数：
git log --pretty=oneline
输出精简版：
def5678901234567890abcdef1234567890abcdef (HEAD -> master) 添加 3 个空文件
abc1234567890abcdef1234567890abcdef123456 添加 ReadMe 文件
💡 那一长串类似
def5678...的字符就是 commit id（版本号）。它是 SHA-1 算法算出来的哈希值，全世界唯一标识这次提交。
4.5 深入 .git 目录
前面说了 .git 是版本库，里面的内容不要手动改。但了解一下能帮你理解 Git 原理：
# 查看 HEAD 文件
cat .git/HEAD
# 输出：ref: refs/heads/master
# 查看 master 分支指向的 commit
cat .git/refs/heads/master
# 输出：def5678901234567890abcdef1234567890abcdef
# 看看 objects 目录
ls .git/objects/
# 输出：23 83 8f 9c c6 e6 info pack
objects 目录是 Git 的对象库。每次 git add，Git 都会在工作区里被修改的文件内容写入 objects 目录的一个新对象里。
查看某个对象的内容：
git cat-file -p def5678901234567890abcdef1234567890abcdef
你会看到这次提交的详细信息：作者、提交者、父 commit、tree 对象等。
总结一下三个关键目录：
index：就是暂存区，add后内容会更新到这里HEAD：默认指向 master 分支的指针refs/heads/master：保存当前 master 分支最新 commit id 的文件objects：包含创建的各种版本库对象及内容
💡 建议在学习过程中多
cat一下.git目录里的文件，把git add、git commit后的变化对应起来。这能让你对 Git 底层有更深的理解。
五、✏️ 修改文件与状态查看
有了初始文件后，我们开始改文件。
5.1 修改文件
直接在编辑器里改 ReadMe 就行：
# 查看当前内容
cat ReadMe
# 输出：
# hello git
# 这是我的第一个 Git 仓库
# 用 vim 或 echo 修改（这里用 echo 演示）
echo "hello version2" >> ReadMe
# 再次查看
cat ReadMe
# 输出：
# hello git
# 这是我的第一个 Git 仓库
# hello version2
5.2 查看仓库状态：git status
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
no changes added to commit (use "git add" and/or "git commit -a")
这段输出告诉你：
- 当前在 master 分支
- ReadMe 被修改了，但还没有 add 到暂存区
- 没有任何文件被 add（“no changes added to commit”）
5.3 看具体改了什么：git diff
git status 只能告诉你"哪些文件改了"，但具体改了什么得用 git diff：
git diff ReadMe
输出：
diff --git a/ReadMe b/ReadMe
index 9c9e1f0..4a97140 100644
--- a/ReadMe
+++ b/ReadMe
@@ -1,2 +1,3 @@
hello git
-这是我的第一个 Git 仓库
+这是我的第一个 Git 仓库
+hello version2
这个输出格式是 Unix 标准的 diff 格式：
-开头的行是被删除的+开头的行是新加的
💡
git diff默认比较的是工作区和暂存区的区别。如果想看工作区和版本库的区别，用git diff HEAD -- 文件名。
5.4 把修改提交到版本库
# 1. 添加到暂存区
git add ReadMe
# 2. 查看状态
git status
# 输出：Changes to be committed: modified: ReadMe
# （注意提示语从 "not staged" 变成了 "to be committed"）
# 3. 正式提交
git commit -m "添加 hello version2 行"
💡 提交后
git status会显示 “nothing to commit, working tree clean”，表示工作区干净了，所有改动都已提交。
六、⏪ 版本回退：玩转 reset
这是 Git 最神奇的功能之一——回到过去。
6.1 为什么要版本回退
实际开发中，改错了、误删了、写崩了这些情况太常见了：
- 写完代码发现思路错了，想重新开始
- 提交了敏感信息（密码、密钥）想撤回
- 老板说"还是用上一版吧"
这时候就需要版本回退。
6.2 准备测试数据
我们准备 3 个版本，依次提交：
# 版本 1
echo "version1" >> ReadMe
git add ReadMe
git commit -m "version1"
# 版本 2
echo "version2" >> ReadMe
git add ReadMe
git commit -m "version2"
# 版本 3
echo "version3" >> ReadMe
git add ReadMe
git commit -m "version3"
# 查看历史
git log --pretty=oneline
# 输出：
# d95c13f... (HEAD -> master) version3
# 14c12c3... version2
# cff9d1e... version1
6.3 git reset 命令详解
git reset 是版本回退的核心命令。语法：
git reset [--soft | --mixed | --hard] [HEAD]
三个参数的区别：
| 参数 | 工作区 | 暂存区 | 版本库 | 适用场景 |
|---|---|---|---|---|
--soft | 保持不变 | 保持不变 | 回退 | 想重新组织提交 |
--mixed（默认） | 保持不变 | 回退 | 回退 | 撤销 add，保留改动 |
--hard | 回退 | 回退 | 回退 | 彻底回退（慎用！） |
HEAD 的几种写法：
HEAD：当前版本HEAD^：上一个版本HEAD^^：上上一个版本HEAD~1：上一个版本HEAD~10：上 10 个版本
也可以直接写 commit id（不需要写全，写前 7 位就能唯一定位）。
6.4 实战：从 v3 回退到 v2
# 1. 先看历史
git log --pretty=oneline
# d95c13f... (HEAD -> master) version3
# 14c12c3... version2
# cff9d1e... version1
# 2. 回退到 v2（--hard 会让工作区也回到 v2 状态）
git reset --hard 14c12c3
# 输出：HEAD is now at 14c12c3 version2
# 3. 查看文件
cat ReadMe
# 输出：version1、version2
# （v3 的内容没了！）
warning： --hard 会把工作区、暂存区、版本库全部回退。工作区里没提交的内容也会被清空！
⚠️ 慎用
--hard！如果只是想让暂存区回到上一个版本，用git reset HEAD 文件名（默认--mixed），这样工作区文件不动。
6.5 回退后又想回去怎么办？
git log 只能看到当前版本及之前的版本，回退后看不到 v3 了。这时候就要用 git reflog：
git reflog
# 输出：
# 14c12c3 (HEAD -> master) HEAD@{0}: reset: moving to 14c12c3
# d95c13f HEAD@{1}: commit: version3
# 14c12c3 (HEAD -> master) HEAD@{2}: commit: version2
# cff9d1e HEAD@{3}: commit: version1
git reflog 记录了本地每一次 Git 命令的操作。从输出里我们看到 d95c13f 是 v3 的 commit id 部分，可以重新 reset 回去：
git reset --hard d95c13f
# 输出：HEAD is now at d95c13f version3
💡
git reflog是 Git 里的"后悔药"。只要你的代码没推送到远程（即使删了分支，reflog 也能找到），用 reflog 几乎都能找回来。
⚠️ 但是！但是！如果你已经
git push到远程了，回退会非常麻烦——下一篇讲远程操作时会详细说怎么处理。
七、↩️ 撤销修改：场景分析
版本回退是针对已提交的内容，但更多时候我们想撤销的是还没提交的工作区改动。
7.1 场景一：工作区改了，没 add
代码写到一半，越写越乱，想恢复到上次 add/commit 时的状态：
# 1. 模拟错误修改
echo "This is a mess" >> ReadMe
# 2. 查状态
git status
# 输出：Changes not staged for commit: modified: ReadMe
# 3. 撤销（注意 -- 不能省！）
git checkout -- ReadMe
# 4. 验证
cat ReadMe
# 错误代码没了！
⚠️
git checkout -- 文件名中的--非常重要！省略后git checkout的含义会完全不同（变成分支切换）。
7.2 场景二：已经 add，但没 commit
git checkout 只能恢复工作区，对暂存区无效。这时候要用 git reset：
# 1. 错误修改并 add
echo "This is still a mess" >> ReadMe
git add ReadMe
# 2. 查状态
git status
# 输出：Changes to be committed: modified: ReadMe
# （注意：提示语变成 "to be committed" 了）
# 3. 把暂存区回退到 HEAD 版本（默认 --mixed）
git reset HEAD ReadMe
# 4. 查状态
git status
# 输出：Changes not staged for commit: modified: ReadMe
# （回到场景一了！）
# 5. 再用 checkout 撤销工作区
git checkout -- ReadMe
💡
git reset HEAD 文件名不会动工作区文件，只会把暂存区里的对应文件"退回去"。
7.3 场景三：已经 add 并 commit 了
如果你已经 commit 了，又想撤回这次提交，可以：
# 回退到上一个版本
git reset --hard HEAD^
⚠️ 但这有前提——你还没有把本地版本库推送到远程（下一篇会讲）。一旦推送了，回退会非常麻烦。
7.4 三种场景对比表
| 场景 | 操作 | 命令 |
|---|---|---|
| 工作区改了，没 add | 撤销工作区 | git checkout -- 文件名 |
| 已 add，没 commit | 先撤销暂存区，再撤销工作区 | git reset HEAD 文件名 + git checkout -- 文件名 |
| 已 add 也 commit 了 | 回退版本 | `git reset – |
为了更直观地判断在何种场景下使用哪个命令，可以参考下面的决策流程图：
hard HEAD^`（慎用） |
八、🗑️ 删除文件
删除文件也是 Git 中的常见操作。
8.1 普通删除文件
# 1. 用 rm 命令删除文件
rm file1
# 2. 查状态
git status
# 输出：deleted: file1
# 3a. 删错了？恢复！
git checkout -- file1
# 3b. 确认要删除？add + commit
git rm file1
git commit -m "删除 file1"
💡
git rm 文件名等价于rm 文件名 + git add 文件名，一步到位把文件从工作区和暂存区都删除。
8.2 删除文件时的状态
| 操作 | 工作区 | 暂存区 | 版本库 |
|---|---|---|---|
rm file1 | 删了 | 没改 | 没改 |
git add file1 | 删了 | 标记删除 | 没改 |
git commit | 删了 | 删了 | 标记删除 |
💡 在 Git 里，删除也是一种修改。你删的文件不是真的从历史里消失了——用
git log还能看到，必要时可以恢复。
九、❓ 本节常见问题解答
学到这里，相信你已经能上手 Git 了。但总有些"灵魂拷问"会让你卡壳。本节挑了 3 个跟本地仓库最相关的疑问，逐一解答。
💡 剩下 6 个问题（颜色配置、
--no-ff合并、stash 用法、冲突解决、远程分支拉取等）会在后续分支管理、远程操作两篇里专门展开。
1️⃣ git log 和 git reflog 有什么区别？
答：
git log：显示当前分支的提交历史，从最新到最远git reflog：显示本地仓库的所有操作记录（包括 reset、commit、merge 等）
最常用的场景：版本回退后想找回去。git log 看不到回退前的版本，但 git reflog 能。
💡 reflog 是 Git 里的"后悔药"，但只对本地有效。
git reflog默认只显示当前分支的操作历史。
2️⃣ master 指向 v3，改成 v2 后再提交 v3 会被覆盖吗？
答：不会。
Git 提交时不会检查你提交的内容是否"已经存在"。即使你 reset 回到 v2 后再 commit v3 一次，v3 也会作为一个新的 commit 出现在历史里（commit id 会不同）。
Git 用 commit id 区分不同提交，即使内容一样，commit id 也不一样（因为时间戳、作者、parent 等元信息不同）。
3️⃣ git reset 能不能加文件名？
答：可以！
git reset 文件名 是 --mixed 模式，只把指定文件从暂存区退回工作区（不影响其他已 add 的文件）：
# 1. 暂存区有 file1 和 file2
git add file1 file2
# 2. 只把 file1 撤出暂存区
git reset file1
# file1 回到工作区，file2 还在暂存区
💡 这种用法在"提交时漏了几个文件"或"误 add" 时特别有用。
十、🎯 实战练习：完成你的第一个完整工作流
理论 + 单命令都讲了，最后来个完整的实战小项目，让你把所有命令串起来。
任务：
- 在
/home/user/test/practice下创建一个叫git-practice的仓库 - 创建一个
notes.txt，写 “Day 1: Git 入门” - 提交一次（commit message: “开始学习 Git”）
- 修改
notes.txt，加上 “Day 2: 版本控制” - 提交一次
- 用
git log --pretty=oneline查看历史 - 回退到第一次提交
- 用
git reflog找回来
参考命令：
# 1. 创建目录并初始化
mkdir -p /home/user/test/practice/git-practice
cd /home/user/test/practice/git-practice
git init
# 2. 创建文件
touch notes.txt
echo "Day 1: Git 入门" > notes.txt
# 3. 第一次提交
git add notes.txt
git commit -m "开始学习 Git"
# 4. 修改文件
echo "Day 2: 版本控制" >> notes.txt
cat notes.txt
# 5. 第二次提交
git add notes.txt
git commit -m "Day 2: 版本控制"
# 6. 查看历史
git log --pretty=oneline
# 7. 回退到第一次提交（用 HEAD^ 表示上一个）
git reset --hard HEAD^
# 8. 用 reflog 找回来
git reflog
# 看到第二次提交的 commit id 后：
git reset --hard <commit_id>
跑一遍这个流程，你对 Git 的理解会上一个台阶。
十一、📌 关键命令速查表
| 命令 | 作用 |
|---|---|
git init | 初始化本地仓库 |
git config --global user.name "..." | 配置用户名 |
git config --global user.email "..." | 配置邮箱 |
git add <file> | 添加文件到暂存区 |
git add . | 添加所有改动到暂存区 |
git commit -m "..." | 提交暂存区内容到版本库 |
git status | 查看仓库状态 |
git diff | 查看工作区 vs 暂存区的差异 |
git log | 查看提交历史 |
git log --pretty=oneline | 简洁版历史 |
git reflog | 查看所有操作记录 |
git reset --hard <commit> | 彻底回退（慎用） |
git reset HEAD <file> | 撤销 add |
git checkout -- <file> | 撤销工作区修改 |
git rm <file> | 删除文件 |
| `gi |
十一、📊 Git 本地工作流全景图
至此，我们已经学习了 Git 本地操作的几乎所有核心命令。为了帮助你从全局视角理解这些命令如何串联成一个完整的工作流，请看下面的全景图：
这张图概括了从初始化到日常修改、提交、查看历史、回退、撤销的完整闭环。建议在实战中对照此图，加深对命令之间联系的理解。
t clone ` | 克隆远程仓库 |
十二、🤔 几个思考题
学完本文，来试试回答这些问题：
1️⃣ git reset --hard HEAD^ 和 git reset --soft HEAD^ 有什么区别？
答：
--hard：工作区、暂存区、版本库全部回退到上一个版本。工作区里没提交的内容会丢失。--soft：只有版本库回退，工作区和暂存区不变。可以重新组织提交。
简而言之：--hard 是"什么都不要了"，--soft 是"我想重新提交"。
💡
HEAD^也可以写成HEAD~1，都表示上一个版本。
2️⃣ git rm 和直接 rm 有什么区别？
答：
rm是系统命令，只删工作区文件，Git 暂存区还保留着这个文件的"记录"git rm把工作区和暂存区的文件都删了，并把"删除"这个操作放到暂存区，等下次 commit
简单说：rm 是普通删除，git rm 是告诉 Git “我准备把这个文件从版本库里删除”。
3️⃣ 误删了工作区文件，怎么恢复？
答：分两种情况：
- 文件已经被 Git 追踪过：用
git checkout -- 文件名可以恢复到最近一次 commit 的状态 - 文件没被 Git 追踪过（新创建但没 add）：对不起，Git 救不了你。可以试试系统回收站或数据恢复软件
💡 这是为什么建议"频繁 add/commit"——给 Git 多留点"后悔药"。
4️⃣ git log --pretty=oneline 里的 commit id 为什么要写那么长？
答：commit id 不需要写全。
Git 用 SHA-1 哈希生成 commit id，理论上只要前 7-8 位就能唯一定位一个 commit（除非你的项目有几万个 commit）。
git reset --hard abc1234 和 git reset --hard abc1234567890abcdef1234567890abcdef123456 效果完全一样。Git 会自动用最短前缀匹配。
💡 但写完整 commit id 更安全（避免前缀冲突），尤其是在
git log输出里复制粘贴时。
5️⃣ 为什么 git checkout -- file 中的 -- 不能省？
答：git checkout 有两个完全不同的用法。
git checkout -- file：撤销工作区修改（用版本库的文件覆盖工作区）git checkout branch_name：切换到指定分支
如果省略 --，Git 可能会把你的 ReadMe 当成"分支名"来切换，触发错误。所以 git checkout -- 后面必须接文件路径时，-- 是必须的。
💡 现在的 Git（2.23+）推荐用
git restore 文件名替代git checkout -- 文件名，语义更清晰。
写在最后
到这里，《Git 本地仓库完全指南》就告一段落了 🎉
我们从"什么是版本控制器"开始，到安装 Git、配置身份，再到创建本地仓库、添加/修改/删除文件、版本回退、撤销修改，把 Git 本地操作的核心场景全部走了一遍。
下一篇我们要进入 Git 最强大也最让人迷惑的功能——分支管理。你会学到：
- 分支到底是什么（用时间线图彻底讲透）
- 创建、切换、合并、删除分支
- 怎么解决合并冲突
- 团队开发必备的分支策略（master / develop / feature / hotfix）
- Bug 分支的正确打开方式
理解分支是迈向 Git 高手的关键一步。我们下一篇见！
📝 思考题答案强烈建议自己敲一遍命令验证一下，光看答案是记不住的。下一节我会带大家一起用 Git 玩一些更有意思的分支操作，到时候你会发现，今天打的基础全用上了。
✅ 本节完…
📝 作者：say-fall | 编辑：say-fall | 🌟 原创不易，如果对你有帮助，记得 👍 点赞 + ⭐ 收藏 哦！
扫一扫
1051
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
