Git实战指南：核心概念、命令操作与误操作恢复

写代码这些年，我带过不少新人，发现一个很普遍的现象：很多人能背出 git add、git commit、git push 三连，可是一遇到分支冲突、误删文件、提交推错远程这类问题，就完全抓瞎。Git 这个工具，靠背命令是学不会的，你得先明白它的底层逻辑为什么这么设计，才能在各种场景里自己做出判断。

这篇内容我打算做一次完整的梳理，从最基础的核心概念讲起，配合可以直接复制的命令和真实输出示例，带你把安装、配置、日常提交、分支协作、远程仓库、撤销回滚、问题排查这些事从头到尾过一遍。适合刚装好 Git 还不太会用的同学，也适合用了一阵子但依然对很多概念云里雾里的开发者。全篇不会跟你扯什么“仓库哲学”，只有能直接上手的东西，以及我踩过坑之后想让你避开的那些细节。

1. 先搞懂 Git 在解决什么问题：不只是一个“云盘”

很多人第一次接触 Git，是把它当“代码云盘”用的，以为它能自动备份代码，跟网盘没区别。这个印象不能说完全错，但会让你错过 Git 真正强大的地方。

Git 是一个分布式版本控制系统，重点在“版本控制”四个字。它不只保存你最后一次代码的样子，而是保存整个项目在时间线上的每一次变化。每一次变化都被记录成一个 commit（提交），包含谁改的、什么时候改的、改了什么内容、为什么改。这种记录方式带来的收益，是你随时可以回到过去任意一个时间点，查看当时的代码长了什么样。

1.1 没有版本控制的混乱日子

我见过太多没有用 Git 的同学是这样管理项目的：项目文件夹里放着 project_v1、project_v2、project_final、project_真_最终版，到最后自己都分不清哪个是最新的。改了三天的代码，领导说“还是用上周那个方案吧”，你只能对着一堆文件手动找，找到了还不确定是不是完整的一版。

这还只是单机情况。如果两个人同时改同一个项目，一个人把另一个人辛苦写的模块覆盖掉，连找回的余地都没有。这种痛，真正经历过的人会懂。

Git 解决的就是这件事。它把所有版本都放在一个本地仓库里，你可以随时查看历史、对比差异、回到旧版本，还能让多人同时在各自分支上工作，最后按规则合并。理解了这一点，下面的概念就好学多了。

1.2 Git 的三种状态：工作区、暂存区、仓库

当初我学 Git 卡了挺久，就是没搞懂暂存区到底是什么意思。后来换了一个思路，用拍照来类比，一下就通了。

• 工作区（Working Directory）：就是你在电脑上能看到的项目文件夹，你正在编辑的文件都在这里。
• 暂存区（Staging Area / Index）：每次提交前，你需要先告诉 Git“把哪些改动放进下一次提交”。暂存区就是这个“待提交清单”暂存的地方。
• 仓库（Repository）：当执行 git commit 后，暂存区的内容被拍成一张“快照”，永久保存在 Git 仓库里，成为一个 commit。

你可以把这个流程理解成拍团队照。工作区是所有人站成一个姿势的状态，暂存区是摄影师喊“准备了”的那一刻，按下快门之后生成的底片才是 commit。如果一个人没准备好，你不会把他拍进去，而是先把他从暂存区拿出去。这就是为什么 Git 提交前要先 git add，目的就是挑选你真正想纳入这次快照的文件。

实际体验一次，你会有直观感受：创建文件后执行 git status，它显示为 Untracked；执行 git add 后，它变成了 staged 状态，位于 “Changes to be committed” 下面；再执行 git commit，它就进入仓库，变成一个带哈希值的提交记录。

1.3 Git 和 GitHub/GitLab 不是一回事

这个混淆非常常见，我必须单独拿出来说。Git 是你本地安装的一个命令行工具，负责版本控制。而 GitHub、GitLab、Gitea 这些，是代码托管平台，它们只是给 Git 仓库提供了一个远程存放和协作的地方，方便多人共享、审查、备份。

Git 完全可以离线使用。你本地 git init 开始一个仓库，之后的提交、分支、回滚，全都不需要网络。只有当你希望把代码推给其他人共同开发，或者换一台电脑继续工作，才需要把本地仓库推送到远程托管平台。

可以这样理解：Git 是你的“记账本”，远程托管平台是你的“公共档案柜”。记账本先要把事情记清楚，归档与否是另一回事。很多人一开始就急着学 remote、clone，却连本地 commit 都还没弄明白，这是本末倒置。

一个小提醒：如果面试时被问“Git 和 GitHub 的区别”，这种回答就能直接判断出你的基础水平。先知道自己手里的工具和平台各自负责什么，比多背十条命令更有意义。

2. 安装与基础配置：让 Git 在这台机器上安家

不管你是哪个操作系统，装 Git 本身都不难，难的是装完以后你要记得做基础配置。很多人跳过配置，第一次 commit 时就收到了 Please tell me who you are 的报错，然后才回头来找“user.name”设置方法。

2.1 各平台安装方式速览

安装 Git 的主流方式我给的一张表：

装完以后，先打开终端或命令行窗口，执行：

bash复制git --version

能输出 git version 2.40.1 之类的结果，就说明安装成功了。

这里要特别提醒 Windows 用户：官方安装包每一步都有选项，很多人习惯一路点“下一步”。但有两个地方建议认真看一眼。第一，选择默认编辑器时，如果你装了 VS Code，建议选 “Use Visual Studio Code as Git’s default editor”；第二，Adjusting your PATH environment 选默认的 “Git from the command line and also from 3rd-party software” 就好。尽量避免只装完 Git Bash 却不加进系统 PATH，否则你在 PowerShell 里输入 git 会提示找不到命令。

安装完成后，Windows 下我建议直接使用 Git Bash 来敲命令，它对 Linux 风格命令的支持更好，也能少踩很多换行符相关的坑。macOS 和 Linux 用户直接用自己的终端就行。

2.2 第一次提交前必做的身份配置

Git 的每一次 commit 都会记录作者信息，所以安装后的第一件事是告诉 Git“你是谁”。

bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

这里有几个常见疑问。为什么必须设？因为提交记录不是一个孤立的代码快照，它还承担着“谁对这次改动负责”的责任。团队协作里，代码审查、责任追溯、统计工作量，全靠这些元信息。

为什么邮箱最好和远程仓库账号一致？因为在 GitHub 这类平台上，提交邮箱如果和你账号绑定的邮箱一致，提交会自动关联到你的头像和主页上；不一致的话，提交记录会显示为“未知作者”，你的贡献度不会被统计。

配置完成后，--global 参数的意思是这些设置会写入你当前系统用户的全局配置文件 ~/.gitconfig。以后这台机器上的所有 Git 仓库都会使用这个身份。如果你只是在某个项目里临时使用不同身份，可以去掉 --global，在那个仓库里单独执行一次。

查看当前所有配置时：

bash复制git config --list

建议把这两项配置完之后，顺手再做两件事。一是把默认分支名统一设置为 main：

bash复制git config --global init.defaultBranch main

二是 Windows 用户建议设置换行符自动转换：

bash复制git config --global core.autocrlf true

macOS 和 Linux 用户则不需要，保持默认即可。换行符的坑我后面还会单独提，这里先埋个伏笔。

2.3 有哪些配置能提升日常效率

等你对 Git 有了基本操作经验后，可以慢慢调整自己的配置，但有几项在刚开始的时候就可以配上。

设置默认编辑器为 VS Code，方便以后执行 git commit 打开编辑器编辑提交信息时直接弹出 VS Code：

bash复制git config --global core.editor "code --wait"

设置别名，减少重复输入：

bash复制git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit

之后输入 git st 等价于 git status。别名的本质是配置项，你可以自定义任意你觉得顺手的缩写。

另外，如果你在终端中打开仓库但不方便看图形界面，我强烈建议了解 git config --global merge.conflictstyle zdiff3。这个配置会在解决冲突时展示出更多的上下文，虽然对初学者来说可能信息量偏大，但从一开始就接触，后面处理复杂冲突会轻松不少。

不要一次性堆太多配置，先保留 user.name、user.email、init.defaultBranch、core.autocrlf 这几项就够跑通了。后续觉得哪里不好用，再翻 git config 文档对症下药。

3. 核心命令实战：完整走一遍日常开发流程

新手最容易犯的毛病是“学命令”而不是“走流程”。如果只记 git add .、git commit -m，你根本不知道每一步之间状态是如何转移的。这一节我建议你跟着代码一起敲，亲手感受一个文件从创建到进入仓库的全过程。

3.1 初始化仓库并完成第一次提交

先在任意位置建一个演示目录：

bash复制mkdir git-demo
cd git-demo
git init

如果上一步配置了 init.defaultBranch，执行完 git init 后当前分支会显示为 main。你可以通过下面命令确认：

bash复制git branch

现在创建一个 README 文件：

bash复制echo "# demo" > README.md
git status

此时 git status 的输出会显示 Untracked files，表示 Git 看到了这个文件，但还没把它纳入版本管理。这个阶段的文件，无论你改多少次，Git 都不会记录。

接着执行：

bash复制git add README.md
git commit -m "first commit"

观察两次命令的输出。在 git add 之后再执行 git status，你会看到 README 出现在 “Changes to be committed” 下，文件名前面是绿色的 new file: README.md。git commit 之后，状态会变成 “nothing to commit, working tree clean”，这表示当前工作区和 Git 记录的最近一次提交完全一致。

查看提交历史：

bash复制git log --oneline

输出大概长这样：

text复制e4a3f2b (HEAD -> main) first commit

前面那一串 e4a3f2b 是这个提交的哈希值前缀，每次提交都会生成唯一的 SHA-1 值，你可以把它理解为这次快照的身份证号。

3.2 文件从“修改”到“提交”的完整生命周期

大多数时候你不是在创建新文件，而是在修改已有文件。记得我刚才说 Git 只记录变化吗？它并不是把整个文件复制一份存下来，而是以一种高效的方式记录每一个版本之间的差异。

现在修改 README.md，把它改成：

text复制# demo
hello git

保存后先执行：

bash复制git status

你会看到 README 列在 “Changes not staged for commit” 下面，说明文件内容变了，但还没放到暂存区。Git 很贴心地区分了两类改动：一类是已暂存的（staged），另一类是未暂存的（unstaged）。

做一个小实验。修改文件后，不先 git add，直接执行：

bash复制git diff

你会看到类似于下面的差异输出：

text复制diff --git a/README.md b/README.md
index c319a35..3d0a85b 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
 # demo
+hello git

这里 - 开头的是修改前的内容，+ 开头的是修改后的新增内容。git diff 不带其他参数时，比较的是“工作区”和“暂存区”的差异。如果你已经 git add 过文件，此时再执行 git diff，就会发现没有输出，因为工作区和暂存区已经一致了；想查看暂存区和上一次提交的差异，要加参数：

bash复制git diff --cached

这两个命令的区别很多人学了很久都记不住。我用一句话总结：git diff 看你还没 add 的改动，git diff --cached 看你已经 add 但还没 commit 的改动。

当你确认改动没问题，执行：

bash复制git add README.md
git commit -m "add hello git"

之后再用 git log --oneline，你会看到两条提交记录。每一条提交都代表着项目的一个有效状态。

3.3 分支操作：创建、切换、合并与删除

分支是 Git 最核心、也最能让新手体会到版本控制优势的功能。为什么需要分支？因为你不想每次开发新功能都直接在主线上改，万一改到一半发现方向错了，整个主线都受影响。分支相当于从主线上拉出一条“平行线”，你在上面随便折腾，不影响别人，等代码稳定了再合并回主线。

常用的分支命令：

bash复制# 查看当前所有分支，带 * 的是当前分支
git branch

# 创建新分支
git branch feature/login

# 切换到新分支
git switch feature/login

# 创建并切换，一步到位
git switch -c feature/login

我比较推荐使用 git switch，它是 Git 2.23 版本开始引入的命令，语义比 git checkout 更清晰。很多人看到老教程里用 git checkout feature/login，也能工作，但新项目完全可以统一用 git switch。

切到新分支后，你添加一个文件：

bash复制echo "login code" > login.py
git add login.py
git commit -m "add login module"

此时你的提交历史里，main 分支指向原来的最后一个提交，而 feature/login 分支则多了一个提交。两个分支像岔路一样，可以各自往前走。

完成开发后，需要把代码合并回主线：

bash复制git switch main
git merge feature/login

如果 main 分支从你拉出 feature/login 之后没有新的提交，合并是“快进”（fast-forward）模式，Git 直接把 main 的指针移动到 feature/login 所在的位置。但如果 main 上也有其他提交，Git 会生成一个“合并提交”（merge commit），把两个分支的历史合并起来。

合并完之后，可以删除这个开发分支：

bash复制git branch -d feature/login

如果分支里还有一些未合并的提交，Git 会拒绝删除，提示你先合并或者改用 -D 强制删除。新手要想清楚为什么要强制删除，避免把自己觉得重要的代码弄丢。

3.4 合并冲突的本质与解决

当两条分支修改了同一个文件的同一行代码时，Git 就不知道该听谁的，于是它只会把冲突标出来，让你自己决策。这就是“冲突”（conflict）的本质——不是 Git 笨，而是它遵守一条原则：绝不擅自覆盖人的决定。

模拟一个冲突。创建项目后，main 分支上有一个文件 hello.txt，内容为：

text复制hello

然后你拉出分支 feature/a，把第一行改为：

text复制hello from feature a

提交。切回 main，把第一行改为：

text复制hello from main

提交。现在执行 git merge feature/a，Git 会提示冲突。

打开 hello.txt，你会看到：

text复制<<<<<<< HEAD
hello from main
=======
hello from feature a
>>>>>>> feature/a

<<<<<<< HEAD 到 ======= 之间是当前分支的内容，======= 到 >>>>>>> feature/a 之间是传入分支的内容。你需要自己判断要保留哪句话，删掉所有标记行，比如手动保留成：

text复制hello from feature a

保存文件后执行：

bash复制git add hello.txt
git commit

注意这里提交时不要加 -m，Git 会帮你生成一个默认的合并提交信息，里面记录了它是怎么解决冲突的。你也可以使用 -m 自己写一句，但建议保留默认信息以便以后追溯。

如果解决冲突过程中你越想越乱，想完全撤销这次合并：

bash复制git merge --abort

这个命令会把工作区恢复到合并开始之前的状态。但它不是一个万能后悔药，如果合并过程中你自己做了其他手动修改，也可能被一并回退。所以执行前先确认清楚。

4. 远程仓库与多人协作：从本地孤岛到团队工作流

本地 Git 用得再熟，如果只把它当个人备份工具，就浪费了一大半价值。远程仓库的真正魅力在于协作，而协作需要你先理解本地和远程之间到底是怎么保持同步的。

4.1 clone 和 remote add 的关系

我见过很多初级开发者，只知道 git clone 拉代码，却不知道如何在已有项目上添加远程地址。

git clone 实际上是完整复制一个远程仓库到本地，它会自动完成三件事：在当前目录创建项目文件夹、把远程仓库完整复制到本地、自动将远程地址关联为 origin。执行后你直接就在一个已经初始化好的 Git 仓库里。

但有些情况下，你是在本地已经创建了项目，之后才想关联远程仓库。这时不能 git clone，而是要手动添加远程地址：

bash复制# 本地项目已在 Git 仓库中
git remote add origin git@example.com:yourname/git-demo.git

# 查看远程地址
git remote -v

# 如果需要更换远程地址
git remote set-url origin git@example.com:yourname/git-demo.git

添加远程地址之后，还要执行一次推送才能让远程仓库“看到”本地代码：

bash复制git push -u origin main

-u 参数很重要，它会建立本地 main 分支与远程 main 分支的关联，以后你直接执行 git push 或 git pull，Git 就知道该和哪个远程分支打交道。

4.2 push、pull、fetch 怎么理解才不混乱

这三个命令是开发者的日常，但很多人只是机械地在用。我画个场景来解释。

你的本地仓库里其实有两套分支视角：一套是你自己的 main，一套是记录“远程仓库在哪个位置”的 origin/main，后者被称为远程跟踪分支。它不会自己更新，必须靠命令去刷新。

git fetch 做的事情，是让 Git 到远程仓库看看别人有没有新的提交，然后把远程更新同步到本地的 origin/main 上。注意，它不会改动你的工作区，也不会改动你当前的代码。执行完 git fetch 之后，你可能发现自己落后了别人很多个提交，这时再去执行 merge 或者用其他方式把远程分支合入本地。

git pull 其实等于 git fetch 加上一个合并（一般是 merge）。它先把远程更新同步到 origin/main，再努力把这个更新合并到你当前的工作分支上。

git push 方向相反，它是把你本地的提交推送到远程仓库。如果远程仓库已经有别人推送了新的提交，而你本地没有，Git 会拒绝推送，提示 “Updates were rejected”。正确的做法是先 git pull，把别人的提交拉下来，解决可能的冲突，再执行 git push。

我建议前期不熟练时，把这三个命令的关系用一句话背下来：fetch 只是“下载消息”，merge 是“把消息合进来”，pull 是“直接下载并合进来”，push 是“把本地改动发出去”。

4.3 免密配置：HTTPS 凭据存储与 SSH Key

后台上传时要求频繁输入用户名密码，真的很烦。网上搜“Git 免密”，出来的方案五花八门，但核心只有两条路：HTTPS 凭据存储和 SSH Key 认证。

先说 HTTPS 方式。你的仓库地址是 https:// 开头的，推送时 Git 会要求输入账号密码。Git 支持把凭据交给系统的凭据管理器保管。Windows 上常配合 Git Credential Manager，安装 Git for Windows 时通常已经自带；macOS 上默认会使用钥匙串，Linux 上则可以使用：

bash复制git config --global credential.helper store

这条命令会记住你输入的用户名和密码，并在后续推送时自动使用。但注意，它默认把凭据明文放在你的用户目录下的 ~/.git-credentials 文件里，不是特别安全。如果你只是图省事，可以用：

bash复制git config --global credential.helper cache

让 Git 在内存里缓存一段时间，默认 15 分钟，也可以调整：

bash复制git config --global credential.helper 'cache --timeout=3600'

不过在现代开发环境里，我更推荐你用 SSH 方式，因为它更干净，也不需要在每次换设备时都依赖系统凭据。

先检查你是否已经有 SSH 密钥：

bash复制ls ~/.ssh/id_ed25519.pub

如果没有，生成一把新密钥：

bash复制ssh-keygen -t ed25519 -C "你的邮箱"

一路回车即可，默认会在 ~/.ssh/id_ed25519 生成私钥、~/.ssh/id_ed25519.pub 生成公钥。然后把公钥内容复制到你的代码托管平台后台的 “SSH Keys” 设置里。最后把远程仓库地址改成 SSH 形式：

bash复制git remote set-url origin git@example.com:你的用户名/git-demo.git

之后你再 push 或 pull，只要私钥仍在当前电脑上，就不再需要输入密码。

安全提醒：私钥文件意味着这台电脑有了“免密推送”的能力。不要把 id_ed25519 这个私钥文件发给任何人，也不要上传到公开仓库。公钥可以公开，私钥绝对不行。

4.4 从 IDE 日志里看到的一长串参数到底在干什么

Git 教程看到这里，你应该已经掌握不少基本命令。但如果你用的开发工具是 VS Code、IntelliJ IDEA 之类，有时打开 Git 输出窗口，会看到类似下面这种命令：

bash复制git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status -z --untracked-files=normal

新手看到这种长命令行往往会慌，以为是多复杂的操作。其实这就是 IDE 在后台调用 Git 时带上的一些配置项。拆开看一点也不神秘。

-c diff.mnemonicprefix=false 的意思是，这一次 Git 命令临时设置一个配置项，不让 diff 使用那些“助记前缀”。默认情况下，Git 的 diff 输出会用 a/ 和 b/ 表示两个比较端。如果你设置 diff.mnemonicPrefix 为 true，它可能会根据对象生成不同的前缀。IDE 显式地设置成 false，是为了让输出格式保持稳定的默认状态，方便程序解析界面展示的 diff。

-c core.quotepath=false 这个大家应该很眼熟。它控制 Git 在输出引用路径时，是否用八进制转义序列代替非 ASCII 字符。你如果仓库里有很多中文文件名，不设置这个选项的话，git status 可能会把文件名显示成 "\350\257\276" 之类的转义形式，肉眼根本看不懂。设置为 false 之后，才会直接显示中文原文。我强烈建议所有中文开发者把这条写入全局配置：

bash复制git config --global core.quotepath false

最后是 --no-optional-locks。这一般是 IDE 在后台刷新仓库状态时故意加的，意思是“做这次状态检查时不要获取 optional lock”。Git 为了保证操作的原子性，会使用索引文件锁。但有些操作天然是“可选加锁”的，比如 git status，它只是为了让自己运行得更快才去拿锁。如果 IDE 频繁在后台执行 status，却在它执行到一半时用户正好在做 commit，commit 就不得不一直等待这个 status 释放锁。加上 --no-optional-locks 就能告诉 Git：别拿那个锁了，慢一点无所谓，但不要挡住我想要真正写入的命令。

这个参数很有用。如果你自己写脚本想定期检查仓库状态，但又不希望脚本干扰正在进行的 Git 操作，完全可以直接在命令行加上它。这种“单次命令参数”的思路也可以扩展：任何你想临时覆盖的配置，都可以用 git -c 配置项=值 命令 的方式，不修改全局配置，也不会影响其他人。

5. 撤销、回滚与误操作恢复：犯错是程序员的日常

刚用 Git 的同学，最怕的就是“改坏了想回去”。其实 Git 的设计里就天然考虑过后悔药这件事，而且还不止一种。关键是你得弄清楚你处在哪个状态，想要回退到哪一步。

5.1 工作区、暂存区、提交三粒度的撤销

Git 的仓库就像一个套娃：工作区改了但没 add，是最浅的一层；add 了但没 commit，是第二层；已经 commit 了，在本地历史里，是第三层。不同层级的撤销命令完全不一样。

如果你修改了一个文件，但还没 git add，你想把这文件的改动全部丢弃，回到上次提交时它长的那样：

bash复制git restore <文件名>

git restore 是 Git 2.23 之后新增的命令，更符合语义。老教程可能让你用 git checkout -- <文件名>，效果一样，但新命令更清晰。

如果你已经 git add 了，但还没 commit，你想把文件从暂存区撤回到工作区，让改动保留但不再是“已暂存”状态：

bash复制git restore --staged <文件名>

注意这里没有真的丢弃任何文件内容，只是把标记从暂存区拿掉。文件还在工作区，你可以继续修改，再决定下一步。

如果你有比较调皮的文件，比如刚才误生成的临时文件根本没被 Git 跟踪，你想直接删掉它：

bash复制# 查看会被清理的未跟踪文件
git clean -n
# 真正删除
git clean -f

-n 是预览模式，只会告诉你“将要删除哪些文件”，不会真删。执行 git clean 要非常谨慎，因为未跟踪文件通常不在版本控制之内，一旦删除很难找回。

我强烈建议把所有“撤销”动作按层分开记忆：

这里的通用规则是：只要改动还没有被写进提交记录，大概率都能比较方便地找回或处理；一旦提交了，就要进入下一个层级考虑。

5.2 用 amend 修改最近一次提交：是方便但也容易踩坑

有时候刚提交完，你突然发现提交信息写错了，比如把 fix: 修复登录 bug 打成了 fix: 修复登入 bug，或者漏提交了一个文件。这时不必新建一个提交，可以直接修改上一次提交：

bash复制git add 漏掉的文件
git commit --amend -m "fix: 修复登录 bug"

--amend 的意思是“修改最近一次提交”。Git 实际上会创建一个全新的提交来替换原来的提交，所以新的提交会有不同的哈希值。如果你已经把这个 commit 推送到了远程，并且和别人共享了这个分支，那就要非常当心了。因为别人本地可能还持有旧提交，你强制“改写”历史之后，很容易导致别人的仓库状态变得混乱。

一个经验法则是：--amend、reset --hard 这类会改写提交历史的命令，只适合用在还没有推送、或者只有你一个人在用这个分支的场景。推送到团队共享分支之后，千万避免使用这种操作。如果需要撤销远端已经存在的某次提交影响，应该用下面说的 git revert。

5.3 reset 与 revert：回退和回滚的区别要想清楚

新手最容易混淆的两类操作是 git reset 和 git revert。一句话总结它们的核心差异：reset 是“抹掉历史”，revert 是“追加一个反向提交来抵消历史”。

git reset 会把当前分支的 HEAD 指针移动到某个历史提交。配合不同的参数，还能决定是否把移动后丢失的变更保留在暂存区或工作区。

先看参数表格：

举例：你提交了三次，想回到第一次提交结束时的状态，但保留后两次的代码改动作为“未提交”状态：

bash复制git reset --mixed HEAD~2

这时你再看 git status，会发现那两次提交涉及的文件都被标记为 modified，工作区内容其实没变，只是 Git 觉得它们是从旧状态开始又修改的。这很适合用来把一整段开发重新整理成更清晰的提交。

再看 git reset --hard HEAD~1，它的效果是挪走最近一次提交，并且工作区也恢复到那次提交之前的样子。这个命令能解决“我想彻底丢掉刚才那次提交”的场景，但风险极大。如果当前工作区里还有你没提交的重要改动，也一并会被清除，且很难恢复。

如果提交已经被推送到远程并影响到了别人，正确的回滚方式是：

bash复制git revert <commit哈希>

它不删除原来的提交，而是生成一个新的提交，新提交的内容是“把指定提交的改动反向操作回去”。这样做的好处是所有人的 Git 历史都还是线性的，不会因为某个人的强推而脱节，团队其他人下次 pull 时也不会有严重冲突。

git revert 的一个很实用的小细节是，它可以一次性回滚多个提交：

bash复制git revert --no-commit HEAD~3..HEAD

如果你需要撤销一大段连续的提交，又不想每个都弹一次编辑器，这个写法会先把所有反向改动放进暂存区，然后由你一次性提交。

6. 常见问题与排查技巧：真实开发中的高频报错

工具这东西，学起来最见效的方式其实是“遇到问题，解决问题”。我把自己这些年被问得最多、也是团队新人最容易踩的坑整理成一个速查清单，你可以把它当成资料收藏，遇到对应问题再翻回来。

6.1 高频报错速查表

还有一个比较隐蔽的错误：fatal: refusing to merge unrelated histories。当你把两个没有公共祖先的仓库强行关联合并时会出现，比如本地 git init 后又添加了远程仓库，而远程仓库已经有一堆提交。这时候如果确认两边内容不会互相覆盖，可以加 --allow-unrelated-histories 临时允许合并，但我更建议你从项目最开始就决定好到底是用 git clone 还是本地初始化，避免这种“血缘不亲”的仓库硬凑在一起。

6.2 中文文件名乱码和 quotepath 设置

这个问题在国内开发者里非常高频。你创建了一个中文文件名的文件，执行 git status，结果看到的却是类似 "\350\257\276\347\250\213.md" 的转义字符。

原因就是我在前面提过的 core.quotepath 默认值是 true。Git 出于兼容性考虑，默认会以八进制转义形式输出非 ASCII 字符。解决办法很直接：

bash复制git config --global core.quotepath false

设置完以后，再运行 git status，中文文件名就能正常显示了。如果你改了配置还是乱码，那可能就是终端本身编码问题，把终端字符集切到 UTF-8 再看。

6.3 误删分支或 reset --hard 以后，代码还能找回来吗

我遇到过好几次，有同事对我说“完了，我 reset --hard 把代码搞没了”，然后又来找我“能不能找回”。

答案是：大多数情况下能，只要操作时间不长。这个“后悔保险”叫 git reflog。

git reflog 会记录你本地仓库里 HEAD 指针每次移动的历史。也就是说，哪怕你执行了 git reset --hard 把一个分支从原本的 commit 挪走了，那条提交只要还在对象数据库里（没有被 GC 清理），它就会出现在 reflog 里。

操作步骤很简单：

bash复制git reflog

输出会列出类似这样的记录：

text复制e4a3f2b HEAD@{0}: reset: moving to e4a3f2b
a8b2c1d HEAD@{1}: commit: add feature B
5c6de10 HEAD@{2}: commit: add feature A

假如你刚才误把 HEAD 从 a8b2c1d 重置回了 e4a3f2b，但你又想回到 a8b2c1d 那个状态，直接：

bash复制git reset --hard a8b2c1d

或者更保险的办法是不要移动原来的分支指针，而是基于那个哈希值新建一个分支来查看内容：

bash复制git branch recover-branch a8b2c1d

这样就算你恢复了代码，也可以先切换过去确认内容，再把不需要的临时分支删除。

reflog 是本地仓库独有的，不会被 push 到远程。这就意味着，只要代码曾经在你本地仓库出现过，而且你还没有手动清理对象数据库，它就有很大概率能找回。所以遇到误操作不要慌，先运行 git reflog 看历史轨迹。

6.4 提醒：养成频繁查看 status 和 diff 的习惯

说了这么多技巧，最后我还是忍不住给一个看似“废话”的建议：多运行 git status 和 git diff。

很多初级开发者的习惯是改完代码直接三连，从不看 git status 到底显示些什么。这个习惯带来的后果是，你根本不知道自己的工作区里藏了哪些文件、哪些修改还没提交、当前分支状态是否干净。一旦出问题，你连“我到底做了什么”都说不清楚。

我看过太多低级事故，比如有人执行 git add . 时，把自己本地的 .env 密钥文件直接提交到了公开仓库，最后不得不费劲清空历史。如果他在 add 之前先看一眼 git status，大概率能发现这个文件不该被提交。

把 git status 当成你写代码的仪表盘，把 git diff 当成每次提交前的最后一层检查。不要嫌麻烦，这两个命令花不了你十秒钟，但能帮你躲掉很多大坑。

关于 Git 的体系，其实远不止这篇文章覆盖的这些内容。像 cherry-pick、stash、bisect、filter-branch、worktree 这些进阶功能，我在日常开发中也经常用到，后面有机会可以再逐个展开讲。但对我个人而言，真正的转折点不是背下来的命令更多，而是有一天我意识到“Git 保存的是提交差异的图，而不是文件夹的拷贝”，从那以后，我遇到很多怪异现象都能自己推导出原因。希望这篇长文也能让你建立同样的直觉。