Git从入门到实战：掌握版本控制、分支管理与撤销回退全流程

第一次打开终端敲下 git --version 的时候，其实心里是没底的。Git 这个工具，你说它难，它翻来覆去就那么几个命令，网上随便一搜全是清单；你说它简单，等你真正在工作区、暂存区、版本库和远程仓库之间绕一圈，很容易就被 reset、revert、checkout 这几个“撤销家族”搞得怀疑人生。

这篇博文不打算给你列一条干巴巴的“命令字典”，而是从“新手拿到 Git 之后，到底按什么顺序学、每个命令在什么场景下用、为什么这么用”来写。内容覆盖安装配置、日常提交、分支管理、远程协作、撤销回退、进阶技巧这几个完整模块，全程配实际案例和踩坑提醒。适合刚接触 Git 的同学，也适合用了一两年但命令老是记混、想看一遍“完整链路”的开发者。

1. 环境准备与首次配置：为什么刚装完 Git 先别急着 clone 代码

很多人的 Git 初体验是这样的：装完软件，立刻找一个开源项目 git clone 下来，然后懵了——提交代码的时候提示要配用户名和邮箱，推送的时候又搞不懂为什么不让你推、为什么每次都要输密码。这些问题十有八九是初始配置没做好。配置这块花五分钟搞定，后面能省下大量时间。

1.1 安装 Git：三个主流系统分别怎么做

Windows 用户最简单，直接去 Git 官网下安装包，一路 Next 就行。但有两个选项要留意：

• 默认编辑器建议选 Notepad++ 或 VS Code，别选 Vim。不是 Vim 不好，而是新手在 Git 里误入 Vim 后，连“怎么退出”都要搜半天。如果你已经装过且选了 Vim，后续可以用命令改回来。
• PATH 环境变量要选 “Git from the command line and also from 3rd-party software”，否则后面在终端里调 git 命令可能找不到。

macOS 用户建议先装 Homebrew，然后 brew install git，这样拿到的版本比较新，后续升级也方便。Linux 用户则优先用发行版自带的包管理器，Ubuntu/Debian 是 sudo apt install git，CentOS/RHEL 是 sudo yum install git。

安装完先在终端验证一下：

bash复制git --version

能返回版本号，说明安装成功。对于 Windows 用户，我还有一个个人建议：尽量用 PowerShell 或 Windows Terminal 操作 Git，别只依赖右键菜单里的 Git Bash。虽然 Git Bash 是完整可用的，但日常开发中你总要面对系统终端，提前适应会顺畅很多。

1.2 首次全局配置：user.name 和 user.email 究竟有什么用

这是新手最不理解的配置项，但它极其关键。Git 在设计的时候，是一个“分布式版本控制系统”，每个人在本地提交，之后再把提交记录推送到远程。问题来了——远程仓库怎么知道某次提交是谁做的？靠的就是你提交时绑定的用户名和邮箱。

也就是说，这个配置不是“登录验证”用的，而是“署名”用的。你提交一次，Git 就把这两个信息写进这条提交记录里，而且默认情况下，同一个邮箱可以被不同的远程仓库账号使用。

配置方法很简单：

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

--global 表示全局生效，也就是这台电脑上所有 Git 仓库默认都用这个身份。如果你在某个项目里想单独用另一个身份，可以去掉 --global，在项目目录里重新配一份，这个项目的配置会覆盖全局配置。

配置完可以查看确认：

bash复制git config --global --list

1.3 核心概念先铺垫：工作区、暂存区、版本库的关系

在往下走之前，建议先建立一个心智模型。Git 对一个项目分了三个区域，很多命令让你觉得晕，本质上是没搞清这三个区域之间的流转关系。

• 工作区（Working Directory）：就是你电脑里肉眼可见的项目文件夹，你改文件、加文件，操作都发生在这里。
• 暂存区（Staging Area / Index）：可以理解成“购物车”。你选购了很多商品（修改的文件），但还没去收银台结账。git add 就是把商品放进购物车。
• 版本库（Repository）：收银台结账后，东西就正式属于你了，此时生成了一个不可变的快照，这个动作就是 git commit。

用一个常见场景串联：你打开一个项目，改了两行代码，这时改动只存在于工作区；执行 git add 后，改动进入暂存区；执行 git commit 后，改动固化成版本库里的一个提交记录。整个过程代码文件本身没变，变的是 Git 追踪的“状态”。

1.4 配置 SSH 密钥：为什么推荐用 SSH 方式连接远程仓库

连接远程仓库有两种主流方式，HTTPS 和 SSH。HTTPS 的特点是每次 push 都要输用户名密码（也可以配置凭据缓存），简单但烦；SSH 的特点是配一次密钥，之后免密操作，体验很顺滑。

生成密钥的命令：

bash复制ssh-keygen -t rsa -b 4096 -C "你的邮箱"

一路回车即可，默认会在用户目录的 .ssh 文件夹下生成两个文件：id_rsa（私钥，自己保留，千万不能泄露）和 id_rsa.pub（公钥，可以给别人看）。然后把公钥内容复制到 Gitee/GitHub/GitLab 的“SSH 公钥”设置页面里就能用了。

新手一个常见的疑问是：私钥和公钥哪个是“锁”哪个是“钥匙”？简单理解，公钥是锁，可以公开装在服务器上；私钥是钥匙，只在自己手里。你发起连接时，服务器用公钥验证你手里的私钥是否匹配，匹配就放行。之后你用 git clone git@github.com:用户名/仓库名.git 这种 SSH 地址时，就不再需要反复输账号密码了。

2. 文件提交这条主链路：status/add/commit 每条命令都藏着细节

新手刚上手，最容易卡壳的地方反而是最常用的几条命令。原因在于这些命令的参数特别灵活，不同写法对应的行为差别很大。我把这条主干链路拆开讲透，你日常提交代码就会非常流畅。

2.1 git status：看状态是第一步，别上来就 add

很多人写代码写得上头，改了一堆文件，直接 git add .，然后 commit。这样不是不行，但很容易把不想提交的文件（比如本地的配置文件、临时文件）一起提交进去。专业的习惯是：提交前先看状态。

bash复制git status

这个命令会告诉你三件事：哪些文件修改了还没进暂存区（红色显示）、哪些文件已经进了暂存区（绿色显示）、哪些文件未跟踪（Untracked）。我几乎每一次 commit 前都会执行一遍。

如果你觉得默认输出太长，可以加一个缩短参数：

bash复制git status -s

-s 是 short 的意思，每个文件只占一行，左边两位表示暂存区状态，右边两位表示工作区状态。这个输出看起来有点抽象，建议你在实际项目里跑一下，用几次就熟悉了。

2.2 git add 的四种姿势：全量添加、指定文件、按块添加

git add 是“把工作区的改动放进暂存区”的命令，但不同的写法适配不同场景。

bash复制# 添加所有改动（包括新文件、修改、删除）
git add .

# 添加指定文件或目录
git add src/index.js
git add docs/

# 添加所有以 .md 结尾的文件
git add *.md

这里我特别想推荐一个很多老手都在用、但教程里很少提的写法：

bash复制git add -p

-p 是 patch 的缩写，意思是“按块暂存”。假设你一个文件里改了两处功能，第一处是与 A 任务相关的代码，第二处是与 B 任务相关的代码，你想分两个提交分别记录，这时候 git add -p 就非常好用。Git 会提示你对每一块改动选择操作：y 表示暂存这一块，n 表示不暂存，s 表示进一步拆分这一块。虽然第一次用会有点懵，但这是提升提交质量的关键技巧。

还有一个实用细节：git add 对“已被跟踪文件”的修改是生效的，但如果新增了一个文件，必须先 git add 后它才被 Git 跟踪。所以别以为“我加了个文件，怎么提交不进去”。

2.3 git commit：-m 和 -am 的区别，以及提交信息的书写习惯

暂存区准备好之后，执行提交：

bash复制git commit -m "提交说明"

-m 是 message 的简写。如果没有 -m，Git 会打开默认编辑器让你输入提交信息，新手很容易卡在这里进退两难。我建议：养成用 -m 的习惯，除非你的提交信息特别长需要多行。

还有一个常见组合参数：

bash复制git commit -am "提交说明"

-a 表示把“所有已跟踪、且已修改”的文件自动放进暂存区再提交。这个参数的精妙之处在于，如果你只是修改了已被 Git 跟踪的文件，没有新增文件，那么这一条命令就省略了 git add 的步骤。但要注意：新增的未跟踪文件，git commit -am 不会管它，必须显式 git add。

关于提交信息，我有一个个人心得：提交信息是写给“三个月后的自己”看的。别写“fix bug”，要写“修复登录接口在空密码时返回 500 的问题”。如果是团队协作，建议和产品需求或缺陷单编号挂钩。

2.4 git log：看懂提交历史，比看懂任何命令都重要

提交做多了，就要学会查看历史。最基础的是：

bash复制git log

但我几乎不会用默认格式，太啰嗦了。日常最常用的是这样几个变体：

bash复制# 每条提交只显示一行（哈希值和提交信息）
git log --oneline

# 用图形化方式显示分支合并历史
git log --graph --oneline

# 显示每次提交改动了哪些文件
git log --stat

# 显示每次提交的具体代码差异
git log -p

--graph 和 --oneline 搭配是我推荐新手最先掌握的，它会把分支的合并、分叉情况画成一张 ASCII 图，你一眼就能看懂项目的演进脉络。

还有一个按作者过滤的写法：

bash复制git log --author="你的名字"

这在“别人说这个模块是你写的，你找出证据”的时候特别好用。

2.5 git diff：改了什么，提交前最后一道检查

git diff 负责回答一个核心问题：到底改了什么？它有几种不同维度的比较：

bash复制# 工作区 vs 暂存区（你改了但还没 git add 的内容）
git diff

# 暂存区 vs 最近一次提交（你 git add 了但还没 commit 的内容）
git diff --cached
git diff --staged    # 和 --cached 等价

# 某两次提交之间的差异
git diff commit1_哈希 commit2_哈希

提交前跑一下 git diff 和 git diff --cached，确认自己确实改的是想改的东西，这个习惯能避免不少“改错文件还提交上去”的尴尬。

3. 分支操作：团队协作的基石，也是生产事故的高发区

如果你只把 Git 当作“个人版的版本存档”，那你只用了它 20% 的价值。Git 真正厉害的是分支模型——开发任务之间互不干扰、并行推进、最后合并。但这部分也是新手最容易搞出问题的地方，尤其是“分支到底是啥”这个问题没建立起来就盲目操作，后面很多命令都会拌脚。

3.1 分支的心智模型：平行宇宙 + 指针

我建议把分支理解成“平行宇宙”。你在 main 分支上，项目是一个状态；你切到 feature/login 分支，就在另一个宇宙里，这个宇宙里的代码和 main 可以完全不同。你在这个宇宙里 commit，完全不影响 main 宇宙。

但 Git 底层实现里，分支其实只是一个“指针”，指向某一次提交。Head（当前 HEAD）也是一个指针，指向你当前所在的分支。每次 commit，Git 会更新当前分支指针，让它指向最新的提交。

这个心智模型解释了为什么创建分支在 Git 里非常轻量——它不是复制一份代码，只是新加一个指针。所以日常开发完全可以放心大胆地多建分支。

3.2 创建与切换：checkout 和 switch 两代命令怎么选

基础的分支操作如下：

bash复制# 查看本地分支
git branch

# 创建新分支（但不切换过去）
git branch feature/login

# 切换分支
git checkout feature/login

# 创建并切换（最常用）
git checkout -b feature/login

不过在 Git 2.23 之后，官方引入了 switch 和 restore 两个命令，目的就是把 checkout 这个“大杂烩”拆开。checkout 既能切分支，又能恢复文件，一个命令管太多事，容易让人误解。新的写法是：

bash复制# 创建并切换到新分支
git switch -c feature/login

# 切换已有分支
git switch feature/login

个人建议：新手直接学 switch，语义更清晰。但如果你的 Git 版本较旧，或者在老旧环境的服务器上操作，只会 checkout 也不会出大问题。

3.3 合并分支：fast-forward 和三方合并的差别

分支开发的最终目的是合并。git merge 是使用频率最高的合并命令：

bash复制# 先切回目标分支（比如 main）
git switch main

# 把 feature/login 分支合并进来
git merge feature/login

这里有一个重要的底层概念：fast-forward 合并和三方合并（merge commit）。

如果当前分支是 feature/login 的直接“祖先”，也就是说 main 分支在分出 feature/login 之后没有任何新提交，那么 Git 可以直接把 main 的指针往前移动到 feature/login 的位置，这就是 fast-forward（快进）合并。它的历史是一条直线，非常干净。

但更多时候，main 分支在 feature/login 开发期间又有别人提交了新代码，这时候 Git 无法直接快进，它需要把两个分支的改动“捏”在一起，生成一个专门的合并提交（merge commit）。这个合并提交有两个父提交，会在 git log --graph 上显示出一个分叉再相交的图形。

对了，如果你希望强行不生成 fast-forward，而总是保留一个合并提交，可以加 --no-ff：

bash复制git merge --no-ff feature/login

很多团队的规范就是要求用 --no-ff，这样每条功能分支的合并记录在历史里都能清楚看到，方便回溯。

3.4 冲突处理：不是灾难，是你主动解决分歧的过程

合并最让人紧张的时刻就是提示：

code复制CONFLICT (content): Merge conflict in src/index.js

看到这个别慌。冲突的意思是：两个分支改了同一文件同一区域，Git 无法替你決定谁的版本对，于是把决定权交给你。打开冲突文件，你会看到类似下面的标记：

java复制<<<<<<< HEAD
你当前分支的代码
=======
feature/login 分支的代码
>>>>>>> feature/login

你需要手动编辑这个文件，把不需要的标记行删掉，保留想要的代码（或者重写成一个融合版本），然后：

bash复制git add src/index.js
git commit -m "合并 feature/login 并解决冲突"

这里有个经验：很多人以为解决冲突就是二选一，其实大部分冲突的正确解法是“融合两个需求”——两边可能都在同一个函数里改了不同的部分，你需要把两部分代码都保留下来，然后再做微调。所以解决冲突时，最好和写这两段代码的同事沟通一下，别擅自丢代码。

冲突并不可怕，可怕的是在不知道该文件原本设计意图的情况下，随手选了某一方的代码。我早期因为怕冲突，长期单分支开发，反而导致主分支天天处于不可用状态。后来改成功能分支 + 定期合并，冲突虽然偶尔出现，但每次都很快处理，团队效率反而高了。

3.5 删除分支：-d 和 -D 的区别决定了你能不能后悔

分支合并完，一般就可以删掉了：

bash复制# 删除本地分支
git branch -d feature/login

-d 是 delete 的简写，它有一个保护机制：如果该分支还有未合并的提交，Git 会拒绝删除并提示你。如果你确实想强行删除一个不要了的、没合并的分支，用大写 -D：

bash复制git branch -D feature/login

别小看 -D，它不检查是否合并，直接删除分支指针。如果该分支上有些提交没有合并到其他分支，那些提交会变成“悬空提交”，理论上还能用 git reflog 找回来，但比较折腾。所以 -D 一定要想清楚再用。

4. 远程协同：clone/push/pull 串起来的完整协作闭环

单机版的 Git 更像文件夹备份，一旦开始 push 和 pull，Git 才真正进入“分布式”的形态。新手学到这里，容易把远程仓库（remote）潜意识里当成“代码的唯一真源”，这个理解其实有偏差。更准确的模型是：每个协作者的本地仓库都是完整的版本库，远程仓库只是一个大家共同约定同步的“中心节点”。

4.1 git clone：不要从零初始化，直接从现有仓库开始

如果你要参与一个已有的项目，不要 git init 之后去网上复制代码，而是直接：

bash复制git clone git@github.com:用户名/仓库名.git

这个命令会做三件事：在当前目录创建一个同名文件夹、拉取远程所有分支和提交记录、自动帮你把这个远程仓库配置为 origin。克隆之后，你在本地就有了一个完整可用的 Git 仓库。

还有一个参数值得了解：

bash复制git clone -b dev git@github.com:用户名/仓库名.git

-b 指定克隆后默认所在的分支。如果项目默认分支不是 main 而是 dev，这个参数就能省一次切换分支的操作。

4.2 git remote：管理远程仓库地址

查看当前配置了哪些远程仓库：

bash复制git remote -v

输出会显示两个地址，一个用于 fetch（拉取），一个用于 push（推送）。对于大多数场景，它们是一样的。如果想添加一个新的远程地址：

bash复制git remote add origin git@github.com:用户名/仓库名.git

这里命名 origin 只是约定俗成，你可以换成其他名字。但建议你和团队保持一致，都叫 origin，降低沟通成本。

4.3 git push：第一次推送为什么要用 -u

本地开发完，想推到远程：

bash复制git push origin main

这条命令表示：把本地 main 分支推到远程 origin 的 main 分支。如果你分支名和远程分支名一致，可以简写为 git push。

但第一次推送一个新分支时，老手会加一个 -u 参数：

bash复制git push -u origin feature/login

-u 是 --set-upstream 的简写，意思是建立本地分支和远程分支的“关联关系”。一旦建立关联，之后这个分支上直接 git push 和 git pull 就不用再指定远程分支名了。这个“上下游”关系是新手经常忽略的概念，但它能省掉很多重复参数。

4.4 git pull 的完整逻辑：fetch + merge 的合体

git pull 表面上看是“从远程拉取最新代码”，但它的内部其实是两个步骤：先从远程把新的提交拉下来（git fetch），然后执行一次合并（git merge），把远程的改动合并到本地当前分支。

这就带来一个建议：新手多理解 git pull 的本质，是一步 fetch + 一步 merge。当你 pull 时遇到冲突，和 merge 分支时遇到冲突的处理办法是完全一样的。

如果想绕过默认的 merge 行为，改用 rebase 方式拉取：

bash复制git pull --rebase

这背后的逻辑我放到后面“rebase”那一节细说，但这里先提一句：--rebase 的目的是让本地未推送的提交“搬”到远程最新提交的后面，保持历史是直线，而不是一个个“合并提交”。很多团队规范就是强制要求用 git pull --rebase，为了历史整洁。

4.5 push 被拒绝时怎么办：non-fast-forward 的真相

新手经常遇到的报错是：

code复制! [rejected]        main -> main (fetch first)
error: failed to push some refs

这句话核心信息是：远程分支上有本地没有的提交，Git 拒绝让你的提交直接覆盖上去。这不代表你的代码有问题，只是规则要求：先同步远程的新提交，再推送你的提交。解决方式：

bash复制git pull --rebase
git push

--rebase 在这里特别推荐，因为它不会产生多余的 merge commit，而是把你的提交“叠”在远程提交之后。强制覆盖虽然可以 git push -f，但千万不要养成习惯——-f 会直接改写远程历史，如果远程有别人的提交，会直接导致他们丢失记录。团队协作中，git push -f 通常只有主分支的维护者在特定场景下才允许使用。

4.6 查看远程分支和本地分支的关联情况

当分支多了之后，你需要搞清楚本地分支和远程分支的对应关系：

bash复制# 查看所有本地分支
git branch

# 查看所有远程分支
git branch -r

# 查看本地分支与远程分支的跟踪关系（带 -vv 可以看到更多信息）
git branch -vv

如果本地分支没有跟踪任何远程分支，push 时 Git 会提示你指定远程分支。这种“分支与分支的关联”是 Git 分布式模型里很核心的概念，建议至少理解到“本地分支可以关联到远程分支”这个层面。

5. 撤销与回退：选错命令可能导致代码白写的三种场景

Git 被称为“后悔药 максимум”，但它也分很多种药效。撤销操作可以说是 Git 里最容易让人头疼的部分，因为涉及不同层级：文件还没 add、add 了还没 commit、commit 了还没 push、push 了……每一层的处理方式完全不同。这一节，我按“从轻到重”的顺序把整个撤销体系讲清楚。

5.1 场景一：工作区改坏了，还没 git add，怎么恢复

你在工作区改了一个文件，改到最后发现思路错了，想恢复成上次提交的状态：

bash复制git checkout -- src/index.js

注意，这条命令会把工作区文件的改动彻底丢弃，而且这条操作不可逆——它会用暂存区（或版本库）里的内容覆盖工作区文件。所以执行之前一定要确认：这个文件里没有你想保留的其他改动。

新版 Git 提供了更语义化的 restore 命令：

bash复制git restore src/index.js

git restore 就是专为“恢复文件”设计的，比 checkout 兼职干这个活语义更清晰。想恢复整个目录也可以：

bash复制git restore .

5.2 场景二：已经 git add 了，想取消暂存（但保留改动）

git add 加错文件了，或者暂时不想提交某个文件，但你想保留工作区的改动。这时不能再用 restore，因为 restore 会直接把文件恢复到上次提交的状态，连保留的改动也一起没了。

正确做法是用 reset：

bash复制git reset HEAD src/index.js

老版本 Git 会提示 Unstaged changes after reset，意思是这个文件从暂存区移到了工作区，但你修改的内容还在。新版本还可以：

bash复制git restore --staged src/index.js

--staged 就是明确告诉 Git：我只取消暂存，不碰工作区内容。

这里你可以看出 restore 和 checkout 的差异：git restore 不带 --staged 时恢复工作区，带 --staged 时取消暂存。同一个命令，用不同参数处理两个场景，非常直观。

5.3 场景三：已经 commit 了，想修改提交信息或把多笔提交还原

提交之后反悔，分几种情况。

只改最近一次提交的信息：

bash复制git commit --amend

这会在原提交的基础上重新“做”一次提交。它会打开编辑器让你改提交信息，也可以直接指定：

bash复制git commit --amend -m "新的提交信息"

--amend 的真实作用是替换最近一次提交，而不是简单改个名字。如果你漏了一个文件，也可以先 git add 再 git commit --amend，这样上一次提交就被替换成包含所有文件的新提交。

想撤销最近一次提交，但保留改动到工作区：

bash复制git reset --soft HEAD~1

HEAD~1 表示上一个提交。--soft 的意思是只移动 HEAD 指针，不做其他任何操作，所以改动会全部保留在暂存区，相当于“提交完又退回了 add 完成的状态”。

想撤销最近一次提交，但把改动退回到工作区：

bash复制git reset --mixed HEAD~1

没有带 --mixed 时，reset 的默认模式就是 mixed，它会取消暂存，让改动回到工作区。相当于“提交和 add 都撤销了，但文件内容保留”。

连改动也彻底不要了：

bash复制git reset --hard HEAD~1

--hard 会把工作区、暂存区全部恢复到上一个提交的状态，当前提交里的所有改动全部消失。这个命令是真正的“危险操作”，因为一旦执行，那些代码改动就从 Git 的管理范围内消失了大半。

我把三种模式的差异整理成表：

5.4 git revert：不改写历史的安全撤销法

reset 的问题是它会“改写历史”——如果你已经 push 到了远程，再用 reset 回退会导致远程分支和本地分支不一致，强行推送就得用 -f，在多人协作场景下非常危险。

此时应该用 revert：

bash复制git revert HEAD

revert 的做法是反向生成一个新提交，把上一次提交的改动“抵消”掉。它不修改历史，只是在历史上多了一条“撤销记录”。这样远程协作的其他人不受影响，pull 下来就自动有了这条撤销。

对于“已经 push 到远程的提交”，我长期使用的原则是：用 revert，不用 reset。因为 reset 会改历史，而改已经公开的历史是对团队的不尊重。只有你的提交还没 push 出去，才敢放心用 reset 清理历史。

5.5 清除未跟踪文件：git clean 的用法与危险

git status 里还有一类“未跟踪文件”（Untracked），它们既不在暂存区，也不在版本库。reset 和 restore 都管不到它们，需要用 git clean：

bash复制# 先看看会删除哪些文件（dry run，不会真正删）
git clean -n

# 删除未跟踪文件
git clean -f

# 连未跟踪的目录也一起删
git clean -fd

git clean 是个高危险命令，因为它删除的是 Git 管理之外的文件，比如本地生成的临时文件、日志文件，删完基本找不回来。所以每次执行前先跑 git clean -n 看看清单，确认没有想保留的文件再下手。

6. 复杂但实用的日常技巧：stash、tag、reflog、rebase 一次讲透

到了最后这一部分，我想讲四个日常出现频率极高、但系统教程里往往讲不透的命令。它们不是“花哨技巧”，而是解决具体痛点的重要工具。

6.1 git stash：手头改到一半，又急着切分支

场景回放：你在 feature/login 上写代码，写到一半，同事说线上有个紧急 bug 需要立刻处理。你不想把没写完的代码提交，但你又要切到 main 分支改东西——不提交的话，切换分支时 Git 不允许你带着一堆未提交的改动过去。

这时候 stash 登场：

bash复制# 把当前工作区改动入栈，工作区变干净
git stash

# 切换到其他分支处理事情
git switch main

# 处理完切换回来
git switch feature/login

# 恢复之前暂存的改动
git stash pop

stash 就像一个临时储物柜，把改动先存起来，等你忙完再取出来。有几个实用参数：

bash复制# 查看暂存列表
git stash list

# 恢复指定暂存（不删除记录）
git stash apply stash@{0}

# 恢复并删除指定暂存
git stash pop stash@{0}

# 删除某个暂存记录
git stash drop stash@{0}

stash 和 stash apply 的区别是：pop 恢复后会自动删除该条记录，apply 会保留。如果你不确定后续还要不要用到，先用 apply 更稳妥。

6.2 git tag：给版本打快照标记

发布版本的时候，我们通常希望给某个提交打一个“里程碑”标记，这个操作叫打 tag。tag 非常轻量，它就是一个指向特定提交的“书签”。

bash复制# 创建附注标签（推荐，包含打标人、时间、说明）
git tag -a v1.0.0 -m "发布1.0版本"

# 创建轻量标签
git tag v1.0.0

# 查看所有标签
git tag

# 查看某个标签对应的提交详情
git show v1.0.0

标签默认不会自动推送到远程，需要显式推送：

bash复制# 推送指定标签
git push origin v1.0.0

# 推送所有标签
git push origin --tags

与 commit 不同，标签通常是不变的，适合标记版本号；提交则经常被修改。理解了这一点，你就知道什么时候用 tag、什么时候用分支了。

6.3 git reflog：误删分支后找回的唯一稻草

很多人不知道，Git 里几乎所有的“误删”都有后悔药，核心武器就是 reflog。reflog 记录的是 HEAD 指针的每一次移动历史，包括你刚才 reset、revert、checkout 的操作。

bash复制git reflog

输出类似：

code复制e5a1b2c HEAD@{0}: commit: 修复登录接口
a3f6d8e HEAD@{1}: reset: moving to HEAD~1

假设你 git branch -D 删除了一个分支，后来发现该分支上有一个重要提交忘了合并。此时你可以用 reflog 找到那个提交的哈希值，然后在新分支上重新指向它：

bash复制git branch feature/login 恢复那个提交的哈希

这个操作能救命的场景太多了。我自己就曾不小心用 reset --hard 丢掉一整天的工作，最后靠 reflog 找回来。所以我想传达的关键信息是：Git 比你想象的更能挽救，但前提是你知道 reflog 是最后一道防线。

6.4 rebase vs merge：为什么团队经常要求 pull 用 rebase

前面多次提到 rebase，这里集中讲透。git rebase 和 git merge 都能整合分支，但思路完全不同。

merge 会保留两个分支的完整分叉历史，然后用一个 merge commit 把历史接起来。优点是历史真实，缺点是图形上分叉很多。

rebase 会把当前分支的提交“拆下来”，依次“重新播放”到目标分支的最新提交之后。结果是历史变成一条直线，干净清晰。

举一个具体例子。你在 feature/login 上开发，main 分支推进了两次提交。如果 merge，历史是一棵树；如果 rebase，Feature 分支上的提交会被整体搬到 main 最新提交的后面，看起来像是你从最新的 main 才开始开发。

很多团队推荐 git pull --rebase，就是为了避免多人协作时产生大量无意义的 merge commit，让 log 变成一条好读的直线。

rebase 的代价是：它会改写提交历史（哈希会变），所以绝对不要对已经 push 并且别人也在使用的分支进行 rebase。否则别人的本地历史就和远程对不上了，会造成很大的混乱。

我整理了一个对比表：

日常工作中，我的建议是：个人功能分支更新之前用 rebase，功能完成合并回主分支时用 merge。两者分工明确，历史既干净又真实。

6.5 一组让我效率翻倍的 alias 配置

最后分享一个不背命令就能提升效率的实用习惯：配置 Git 别名（alias）。Git 允许你把常用命令缩写成简短的形式：

bash复制git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.lg "log --oneline --graph --all"

设置完之后，git st 就是 git status，git lg 就是那条带图形的漂亮日志。用熟了之后，手速明显提升。

有个我用了很久的组合别名，适合查看完整提交树：

bash复制git config --global alias.tree "log --graph --oneline --all --decorate"

如果你嫌这些配置太多，也可以直接编辑 ~/.gitconfig 文件。这里有个提醒：别名只在你自己电脑上有效，换一台电脑需要重新配置，所以可以把常用别名写进自己的“环境配置脚本”里，以备随时迁移。

7. 日常开发中最值得背下来的 Git 工作流建议

这篇博文写到这儿，命令已经覆盖得比较全了，但还有一个“组合使用”的问题。命令单拎出来都能看懂，真正难的是在具体场景里知道该用哪条。最后一节我想结合个人经验，给大家一套可以直接套用的工作流。

7.1 推荐给新手的功能分支工作流

如果团队没有完善的 Git 规范，我会推荐这样一种简单、稳当的工作流：

1. 从 main 分支切一个功能分支：git switch -c feature/任务描述
2. 在功能分支上开发，多提交、小步走：git add + git commit，把一次任务拆成多次逻辑清晰的提交
3. 开发完成后，更新主线代码再合并：git switch main，git pull --rebase，然后 git switch feature/任务描述，git rebase main
4. 切回 main 完成合并：git switch main，git merge --no-ff feature/任务描述
5. 推送并删除功能分支：git push origin main，git branch -d feature/任务描述

这套流程的逻辑是：功能分支隔离风险，rebase 让历史干净，merge --no-ff 保证每次功能合并在历史上都有清楚记录。它不是唯一方案，但足够通用。

7.2 提交信息的规范写法与 lint 工具

个人博客不讲究，但团队协作时，提交信息规不规范直接影响回溯效率。目前很多团队采用 Conventional Commits 规范，格式如下：

code复制类型(可选范围): 描述

fix(login): 修复空密码登录时返回401的问题
feat(order): 新增订单批量导出功能
docs(readme): 更新环境部署说明

常用类型有 feat（新功能）、fix（修bug）、docs（文档）、style（格式）、refactor（重构）、test（测试）、chore（构建/工具）。配合社区工具 commitlint 和 husky，可以在提交时自动校验格式，不符合规则直接拦截。

7.3 团队协作中的“红线操作”

最后列一份我在实践里总结的“红线清单”，这些操作一旦犯错，轻则干扰队友，重则丢失代码，务必警惕：

• 对公共分支（main/dev）不要随意 git push -f。任何强制推送都必须先和团队确认。
• 不要让本地 main 落后远程太多。提交前先 git pull --rebase。
• 不要轻易 git clean -fd，执行前先 -n 看清单。
• 不要对一个别人正基于它开发的分支做 rebase。
• 不要在 stash 里存太多东西就忘了，每周清理一次临时 stash。
• 不要迷信 --hard，reset 之前想想能不能用 revert 代替。

我做 Git 相关操作已经有很长的年头，最大的体会不是“命令背得越多越强”，而是“越理解 Git 的底层模型，命令就越不容易记混”。什么时候用 merge、什么时候用 rebase，看一次历史图就明白；什么时候能 reset、什么时候必须 revert，想清楚“这个提交是否公开了”就足够。希望这篇指南能帮你在 Git 这条路上少踩几个坑，把这套版本管理工具真正变成你的生产力，而不是让你头疼的包袱。