企业官网建设流程全解析

带过几轮新人之后，我发现大家在 Git 里挣扎的日子惊人地相似：分支切来切去迷了路、commit 打错了想反悔、改到一半发现改了别的分支的代码、rebase 到一半冲突堆成山直接心态爆炸。标题里这些命令——git commit、branch、checkout、switch、rebase、HEAD、相对引用、reset、revert、cherry-pick——基本覆盖了日常开发里 90% 的 Git 操作场景。这篇文章我不打算按官方文档的顺序把每条命令罗列一遍，而是从“提交记录到底是什么、HEAD 怎么移动、历史如何改写、提交如何搬运”这条主线出发，把它们的底层逻辑串起来讲，附带我实际踩坑换来的经验和可以直接抄作业的命令组合。

不管你是刚接触 Git 半个月的新手，还是用了两三年但遇到回退场景还是会心慌的“熟练工”，这篇文章都值得读完。新手可以从头到尾过一遍，建立完整的操作地图；老手可以直接跳到第 3 章和第 6 章，看看 reset 和 revert 的边界、rebase 黄金法则那些细节，多少能补上一些盲区。

1. 先把地基打好——分支、HEAD 与提交记录的本质

很多人用 Git 两三年，命令背得很熟，但一遇到“HEAD 游离了”“相对引用到底该怎么写”这种问题就抓瞎。根源在于一直把 Git 当作“能存版本的网盘”在用，从来没有从底层数据模型的角度理解它。所以先别急着敲命令，把三个核心概念彻底搞清楚，后面所有的操作都会变得理所当然。

1.1 分支的本质：一个会移动的贴纸

Git 里的分支，本质上不是文件夹的拷贝，也不是一份独立代码的副本，它只是一个指向某个 commit（提交对象）的指针。说得更直白一点，分支就是贴在一堆提交记录上的一个标签，告诉 Git“当前这条开发线的最新点在哪里”。

每次你执行 git commit，Git 会生成一个新的提交对象，这个提交对象里保存着三样东西：本次改动的内容快照、父提交的哈希值、提交时的作者和说明信息。然后最关键的一步是，Git 会把当前分支这个指针从原来的 commit 挪到新的 commit 上。

git add . git commit -m "feat: 添加用户注册功能"

执行完这两条命令之后，commit 上发生了什么？

如果你只有一个 main 分支，原本指向 A 提交（哈希值形如a1b2c3d），新提交 B 的父节点就是 A，然后 main 指针自动从 A 移动到 B。所以分支永远是“最新的位置”，而历史提交靠父子关系连接成链。这也是为什么 Git 官方文档会管分支叫“可移动的指针（movable pointer）”。

理解了这一点，你就会明白几个容易混淆的事：

第一，分支名本身没有存储代码，它只是指向某个提交。删除分支只是删掉了这个“指针”，那些提交对象如果还有别的引用指向它们，数据就还在，不会被立刻清掉。

第二，同一个提交可以被多个分支同时指向。比如你从 main 拉了 feature 分支，在没有新提交之前，main 和 feature 指向的是同一个 commit。

第三，三条分支“分叉”并不是代码复制了三份，而是它们从共同的祖先提交出发，各自沿着不同的方向新增了提交，形成了两条不同的链。

把分支理解为“贴纸”，而不是“目录”，很多操作就说得通了。所谓“切换分支”，本质上就是“把 HEAD 这个指针移动到另一个分支所指向的提交上，并同步更新工作目录里的文件内容”。

1.2 HEAD：你现在站在哪一行

HEAD 同样是 Git 的一个指针，只不过它的含义更特殊——它指向的是“当前所在位置”。在绝大多数正常状态下，HEAD 指向的是某一个分支名，而不是直接指向提交。

我用一个图来解释（虽然规范不让用 diagram，但这个结构用文字很难绕开，用缩进描述一下）：

提交链： A <-- B <-- C <-- D 分支引用： main → D HEAD 引用： HEAD → main

这种情况下，执行 git log 你会看到 D、C、B、A 的提交记录。如果此时你执行 git commit，新提交 E 会接在 D 后面，然后 main 和 HEAD 一起移动到 E。

而“detached HEAD”（游离 HEAD）状态是什么呢？当你直接 checkout 到一个具体的提交哈希（或者某个不带分支名的 tag）时，HEAD 就不再指向分支，而是直接指向一个提交对象：

提交链： A <-- B <-- C <-- D HEAD 引用： HEAD → D（直接）

在这个状态下执行 git commit，新提交 E 会生成，但它没有任何分支指向它。等你还想切回主分支的时候，E 就变成了一堆悬空提交（dangling commit），唯一的出路是通过 reflog 找回它的哈希。所以新手看到 detached HEAD 提示时会很慌，原因就在这里。

那怎么退出 detached HEAD 状态？最安全的做法是：如果只是想看一眼某个历史提交，看完立刻切回原分支：

git checkout a1b2c3d # 查看历史提交 git checkout main # 回到主分支，完事

如果想基于这个历史提交开新分支做实验：

git checkout -b hotfix a1b2c3d

这个命令会先创建指向 a1b2c3d 的 hotfix 分支，然后把 HEAD 切到 hotfix。之后你在这个分支上做的一切提交都有分支兜底，不会被弄丢。

1.3 相对引用保姆级解读：^ 和 ~ 的前世今生

很多命令需要你精确指定“某个提交”，但你不可能每次去翻一长串哈希值。相对引用就是解决这个问题的：用^和~基于当前位置进行“移动”。

这两个符号的官方解释很容易让人背混，我直接用两个实际例子讲。

^表示“第几个父提交”。普通提交只有一个父提交，但合并提交（merge commit）有两个父提交。main^表示 main 的第一父提交，main^2表示第二父提交。所谓的“第一父提交”就是合并时你所在的那个分支（执行 merge 前所在分支）的末位提交，“第二父提交”是被合并进来的那个分支的末位提交。

~表示“往上追溯第几代”。main~1等价于main^，表示 main 的上一个提交；main~3表示往上数三代的提交，等价于main^^^。

写一个例子让你看到区别。假设提交历史长这样：

main 分叉点： A <-- B <-- M（merge commit） \ / feature 分支： C <-- D <-- E

M 是合并提交，它有两个父提交：第一父是 B，第二父是 E。这种情况下：

• main~1指向 B（因为 ~ 不区分第几个父，默认沿第一父链往上走）
• main^1也是 B
• main^2指向 E（第二父）
• main~2指向 A（沿第一父链往上走两步）
• main^2~1指向 D（E 的父提交）

这个区别在日常命令里非常常用。比如 reset 时想回退到合并之前的第一个父提交，直接用git reset HEAD~1就会退到 B，但如果你的意图是退到 E 那一侧，就必须写HEAD^2。我在实际工作中至少遇到过三次因为搞混^和~把 reset 的目标搞错，然后通过 reflog 找回的糗事。

相对引用常用场景补充：

不需要把所有这些背下来，只需要记住一句话：看家谱用 ~，分辨父母用 ^。在键盘上敲的时候，~离主键区近，常用于“往前走几步”这种平移操作；^常用于 merge commit 这类有多条父链的场景。

2. 移动与切换——branch、checkout、switch 实操全解

理论清完，接下来是最高频的日常操作：新建分支、切换分支、管理分支。这里有一个大坑需要单独拿出来讲：git checkout这个命令承担了太多职责，经常让人混淆。

2.1 checkout 的三重身份与 switch 的诞生

在老版本的 Git 里，checkout 身兼数职，它可以：

第一，切换分支：git checkout feature，把 HEAD 从一个分支移到另一个分支。

第二，恢复文件：git checkout -- index.js，把某个文件还原成暂存区（或者 HEAD）里的版本。这个用法经常在“我把代码改坏了，想放弃修改”的场景中出现。

第三，创建分支并切换：git checkout -b new-feature。

这三个操作彼此之间没有任何语法相似性，全凭肌肉记忆。Git 团队在 2.23 版本引入了两个新命令把职责拆开：

• git switch：专门负责切换分支
• git restore：专门负责恢复文件

我个人的建议是：新写的脚本和项目里，优先用 switch 和 restore 替代 checkout，语义更清晰，代码评审时别人也知道你的意图。但在大量老项目、教程和 CI 脚本里看到的还是 checkout，所以两个都要看得懂。

日常切换分支的几个场景和命令：

git switch main # 切换分支 git switch -c fix/login-page # 新建分支并切过去 git switch --detach a1b2c3d # 切到历史提交（游离态） git restore index.js # 放弃工作区对该文件的修改 git restore --staged index.js # 把文件从暂存区移回工作区，像 git reset HEAD 的新写法

注意git restore --staged是一个很常用的“撤销 git add”操作。老写法是git reset HEAD index.js，语义非常糟糕，因为 reset 看起来像要重置整个仓库。restore 的命名直观多了：从暂存区“恢复”到工作区。

2.2 切换分支的正确姿势：先确认工作区干净

切换分支最经典的报错是：

error: Your local changes to the following files would be overwritten by checkout

意思是你要切到的分支上这些文件的内容和你当前工作区里没提交的修改冲突，切过去你的修改会被覆盖，Git 出于安全考虑拒绝执行。

我应对这个情况有固定的流程：

第一，先查看状态和差异：

git status git diff # 看看改了什么

第二，如果修改不打算要了，直接丢弃：

git restore index.js

第三，如果修改还想留着，但不想提交，可以暂时“藏起来”：

git stash push -m "half-done login refactor" git switch feature # 之后想恢复修改 git stash pop

stash 堆栈是每个写代码的人都要掌握的逃生通道。它的原理是把当前工作区和暂存区的改动存成一个特殊的提交对象，然后清空工作区让你可以安全切换分支；等切回来再用git stash pop还原。多个 stash 可以用git stash list查看，用git stash apply stash@{2}恢复指定项。

我经常看到新人有两个坏习惯：一是把所有文件塞进一个 stash，导致 stash 里什么东西都有，pop 时冲突解决到怀疑人生；二是 stash 从不命名，三天后根本想不起来里面放的是什么。正确做法是给 stash 加-m描述，并且尽量让每次 stash 只包含逻辑上相关的一组改动。

第四，如果这个修改值得留下，直接在当前分支提交，再切过去。别犹豫，提交历史脏一点可以用 rebase 清理，但代码弄丢了才是真正的损失。

2.3 分支管理：创建、重命名、删除的正确时机

分支管理的几个常用操作：

git branch # 列出本地分支，当前分支前有 * 号 git branch -a # 列出所有本地和远程分支 git branch -vv # 显示每个分支跟踪的远程分支，极其推荐 git branch -m old-nm new-nm # 重命名分支 git branch -d feature # 删除已合并的分支 git branch -D feature # 强制删除未合并的分支 git branch --merged # 列出已合并进当前分支的所有分支

这里有两个场景值得注意：

场景一，删除分支失败。执行git branch -d feature时报错“not fully merged”。这代表该分支里有尚未合并到当前分支的提交，Git 怕你丢代码。如果你确认这些提交不要了才用-D，否则得先合并或者 cherry-pick 关键提交。

场景二，远程分支删除后本地一堆残留。养成定期清理本地陈旧分支的习惯：

git remote prune origin git branch --merged | xargs git branch -d

第二条命令会把所有已经合并到当前分支的分支批量删除。执行前先git branch --merged看一眼列表，避免误删。

关于分支命名，我个人的经验是：类型/描述 的结构比随便起名可读性强得多。feature/user-login、fix/checkout-bug、chore/update-deps这类命名在团队协作时一眼就知道分支目的，配合 CI 的按分支规则触发流水线也方便。分支活不过两周是常态，超过一个月的分支要么已经迷失方向，要么就是没有按计划合并，需要警惕。

3. 回撤代码——reset、revert、checkout 的撤销之道

代码写错了、提交错了、推到远程了才发现有 bug——这是 Git 使用频率最高的“后悔药”时刻。撤销在 Git 里不是一条命令打天下，至少在变更历史的舞台上站着三个玩家：reset、revert 和 checkout，它们的适用场景和风险级别完全不同。

3.1 reset 的三重境界：soft、mixed、hard

git reset的常规理解是“把当前分支的提交记录往后退”。但它真正做的是把分支指针移动到指定提交，然后根据参数决定暂存区和工作区怎么处理。

参数决定的是“变更的波及范围”。用一个具体的三段式使用场景来解释：

假设你在 main 分支上有提交 A、B、C，HEAD 指向 C。工作区里你还没 add 的文件叫 X，暂存区里有刚 add 的文件 Y，而 C 提交里包含的内容是 Z。现在你想回退到提交 B：

git reset --soft B

执行后发生了什么？分支指针从 C 挪到 B，提交 C 在分支历史里消失了。但暂存区和工作区都被保留，也就是说 C 的改动内容 Z 还躺在暂存区里，可以随时重新提交。--soft的语义就是“保留所有变动，只动分支指针”，最常用于“刚才那次提交漏了文件”或“提交说明写错了，想换个 message 重新提交”的场景：

git reset --soft HEAD~1 git add . git commit -m "feat: 正确的提交说明"

git reset --mixed B（默认模式）除了把分支指针回退，还会把暂存区重置成 B 的状态，但工作区文件内容保持不动。执行完你会发现：C 里的改动从“已暂存”变成了“已修改未暂存”的状态，diff 仍然能看到改动内容。这是最常用的撤销提交模式，相当于“把提交拆回工作区”，可以重新分组提交或者放弃一部分改动。

git reset --hard B是三个模式中最危险的一个：分支指针回退、暂存区清空、工作区的文件内容也全部恢复到 B 的样子。C 提交里的一切改动都会瞬间消失。如果你没有把这个提交推到远程，且本地也没有任何备份，这些代码等于灰飞烟灭。

我用一张表格把三个模式整理清楚：

关于 reset 的一个铁律：已经 push 到远程的提交，除非你能确认只有你一个人在这个分支上干活，否则不要用 reset 改写。因为别人可能已经基于 C 提交做了新开发，你本地把 C 从历史上抹掉再强制推上去，对方下次 pull 时会出现大量诡异冲突，极其痛苦。

3.2 为什么 revert 更适合团队协作

git revert不是把分支指针往回拨，而是新建一个提交，这个提交的改动内容是“反向应用”目标提交的变更。比如你在 C 提交里加了一行代码，revert C 会产生一个新提交 D，D 的内容是删除那行代码。

git revert a1b2c3d

执行这个命令后，Git 会自动生成一个反作用的提交，并打开编辑器让你填提交信息，默认文案是Revert "原始提交的说明"。

revert 和 reset 最大的区别在于：revert 不会删除历史，只会追加一份新的提交来抵消之前的错误。这带来的好处是，所有协作成员 pull 时看到的是一段正常的提交历史，旧的错误提交还在那里，新提交明确记录了“这里撤销过什么”。这在多人协作里非常关键——你不需要强制推送，不需要处理别人基于旧提交产生的冲突，大家各自 pull 后都回到正确的代码状态。

还有一个细节：revert 对 merge commit 的处理比较特殊。直接git revert一个 merge commit 会报错，因为 Git 不知道应该“反撤销”哪一支的变化。必须显式指定主分支方向：

git revert -m 1 a1b2c3d

-m 1表示保留第一父提交（也就是合并时所在的分支）的内容，撤销来自第二父分支（被合并进来的分支）的改动。这个操作在线上发布后回滚的场景里经常用到，值得提前演练一遍。

3.3 撤销实战：从误提交到远程回滚

日常工作中，我会根据“改动是否已经推到远程”来判断走哪个方案：

场景一：还在本地，只是提交信息写错了

git commit --amend -m "fix: 新补充说明"

这不是删除提交，而是把当前暂存区的改动合并进上一次提交，并替换提交信息。注意如果上一次提交已经 push 过，这种操作也会改写历史，需要谨慎。

场景二：还在本地，提交内容和信息都不对

git reset --soft HEAD~1 # 或者 git reset HEAD~1

走 soft 模式是因为你想保留改动重做，走 mixed 也无妨，反正代码还在工作区。这个场景最常见的失误是凭手感敲了一个git reset --hard HEAD~1，结果把刚刚写了一下午的代码全部弄没。所以我有一个习惯性动作：在需要丢弃改动前，无论如何先看一眼 git log 和 git diff，确认当前“损失”的内容是什么。

如果真误敲了 --hard，别慌，用git reflog找回：

git reflog # 找到你执行 reset 之前的那个提交哈希 git reset --hard 上一串哈希值

reflog 记录的是 HEAD 的所有移动历史，只要你的操作发生在这台机器的仓库里，八成都能通过 reflog 救命。前提是你没清理过 reflog 过期记录，且没有 GC 把这部分对象回收。

场景三：已经推到远程，需要回滚

不要 reset，直接用 revert：

git revert HEAD~2..HEAD # 如果最后两个提交都要撤销

revert 多个连续提交时，可以一次传一个区间。注意 revert 之后的提交历史会多出一个或几个反向提交，如果要发布到线上，请走正常的合并和发布流程，而不是强制推送。

我见过一个非常危险的团队操作：线上出了紧急 bug，资深工程师本地 reset 到两天前的提交，然后git push --force，硬生生把远程历史改写，其他同事的提交全部“凭空消失”。等大家 pull 时出现大规模冲突，浪费了一整个下午排查。从那以后团队规定：远程分支一律不准 reset，只准 revert。这条规则值得写进所有团队的 Git 规范里。

4. cherry-pick——把提交从一个分支搬到另一个分支

cherry-pick 直译是“摘樱桃”，它的功能正如名字：把其他分支上的某个提交单独“摘”到你当前所在的分支上。日常开发中它的应用场景非常多，学会之后很多看起来麻烦的事情会瞬间简单很多。

4.1 什么时候需要 cherry-pick

场景一：hotfix 需要同步到多个分支。你在 main 分支上修复了一个生产 bug，提交为fix/critical-login-bug（哈希为f123abc），但当前维护的 release/2024 分支也需要这个修复。你不能直接把整个 release 分支合并到 main，因为会把一堆还不该发布的开发功能也带进去。正确做法是把那个 fix 提交 cherry-pick 到 release 分支。

git switch release/2024 git cherry-pick f123abc

场景二：自己开了个实验分支，上面写了几十行不错的实现，但后来发现实验方向偏了，不想合并整个分支，只想把其中一个实现比较好的提交挪到主开发分支上。

场景三：协作时同事把某个功能写在了他个人的功能分支上，还没合并到主干，但你需要依赖其中一小段公共工具代码。让同事单独把那个提交 cherry-pick 给你，或者你自己从他分支上 cherry-pick 过来，都比等整个分支合并更灵活。

4.2 cherry-pick 完整流程与冲突处理

cherry-pick 的原理是：读取目标提交引入的 diff，然后尝试在当前分支的代码状态上将这个 diff 打上去。它在 Git 内部会经历：生成一个临时的提交对象 → 计算与应用补丁 → 创建新提交。因为这个过程是“重新应用补丁”，所以当目标提交所修改的文件在当前分支上有不同的内容时，就会产生冲突。

一个典型的带冲突 cherry-pick 流程：

git cherry-pick f123abc

如果一切顺利，你会发现历史里多了一条新提交，它的提交信息保留了原提交的信息，但哈希是不同的（因为父提交变了、提交时间变了）。

如果冲突了，Git 会停下来并提示 CHERRY_PICK_HEAD 状态。此时你要做的是：

1. 打开冲突文件，解决冲突标记（<<<<<<<、=======、>>>>>>>中间的部分）
2. 将解决后的文件加入暂存区：

git add conflict-file.js

3. 继续执行：

git cherry-pick --continue

如果你觉得这个提交干脆不要了，可以用：

git cherry-pick --abort

这个命令会把当前分支恢复到执行 cherry-pick 之前的状态，非常可靠，任何中间产生的冲突和暂存修改都会被清理掉。在没把握的时候大胆用 abort，不会造成不可逆的损失。

cherry-pick 还有一个批量用法，一次性摘多个提交：

git cherry-pick a1b2c3d e4f5a6b c7d8e9f

也可以摘一个区间，但注意区间写法是“起点之后到终点为止”：

git cherry-pick A..B

这个语法和 diff 的区间不太一样，容易踩坑。A..B表示“从 A 之后到 B 为止的所有提交”，不包含 A 本身。如果想包含 A，写成A^..B。

4.3 cherry-pick 的进阶技巧与注意事项

第一个技巧：当一次 cherry-pick 多个提交时，如果每一个提交都有冲突，会非常痛苦。我的建议是一次只 cherry-pick 逻辑上独立的提交，每次解决完冲突后立即继续，不要攒着好几个一起处理，否则心理压力会成倍放大。

第二个技巧：配合-n参数一次性应用多个提交但不自动生成提交。例如你想把三个提交的改动合并成一个提交带过来：

git cherry-pick -n a1b2c3d e4f5a6b c7d8e9f git add . git commit -m "chore: 合并来自实验分支的三块改动"

这样会得到一个改动内容等于三个提交之和的单独提交，很干净，特别适合整理公共代码的引入。

第三个注意事项：cherry-pick 会产生重复的提交。如果之后你又把那个原分支合并了过来，Git 在合并时会尝试应用相同或相似的 diff，可能再次产生冲突或者出现重复代码。所以使用 cherry-pick 前想清楚——如果目标提交终究会通过合并进入这个分支，就不需要先 cherry-pick 一遍，纯粹给自己找事。

第四个注意事项：不要在 cherry-pick 过程中顺手改别的文件。cherry-pick 进行期间，Git 处于一种“半应用”的中间状态，此时你再做别的改动，一旦需要 abort，那些额外改动也可能被牵连清理掉。遵守“一次性只干一件事”的原则。

5. rebase 变基——让历史变干净，还是让历史变危险？

rebase 可能是标题列表里争议最大、操作失误代价最高的命令。它的官方名字叫“变基”，意思是为提交链更换“基底”，本质上是从目标基准点开始，把当前分支上的一系列提交重新播放一遍。

5.1 rebase 的本质：提交的重新播放

假如你在 feature 分支上从 main 的 A 点分叉，之后 main 前进了 B、C 两个提交，feature 分支上自己新增了 D、E 提交。传统 merge 的做法是把两个分支的终局合并成一个新的 merge commit，提交历史上会有明显的分叉和合并节点。而 rebase 的做法是：把 D、E 两个提交“摘下来”，重新应用到 main 最新的 C 提交之上，让 feature 分支看起来是从 C 连续长出来的。

git switch feature git rebase main

执行完的提交历史变成直线：

A <-- B <-- C <-- D' <-- E'（feature）

D'和E'是新生成的提交，内容和 D、E 相同，但父提交和提交时间都变了，所以哈希完全不同。

rebase 的价值有两个：一是让提交历史变成一条干净的直线，方便 code review 和追溯；二是你可以把一个功能分支上十几条“修一下测试”“临时改个变量”的琐碎提交压缩成清晰的两三个逻辑提交。

5.2 交互式 rebase：整理历史的工具箱

git rebase -i是真正的进阶玩家工具。它允许你以交互方式整理提交历史，常用指令包括：

git rebase -i HEAD~5

执行后会打开一个编辑器，里面按时间从早到晚列出最近 5 条提交，每行开头是可执行指令，常用几个：

举个例子，我想把最近 3 个提交压缩成一个“feat: xxx”，就在编辑器里这样写：

pick c2d4d2c feat: 添加登录页面骨架 squash 2a4b5f6 fix: 修登录框样式问题 fixup 7b8c9d0 chore: 补充登录页占位资源

保存退出后，Git 会按顺序执行：保留第一个提交，然后把后面两个提交压缩进第一个提交里。输出一个新提交，信息按 squash 规则合并。这是整理提交历史最常用的一组操作。

这里我提醒三个容易出错的地方：

第一，交互式 rebase 的提交顺序是“从早到晚”还是“从晚到早”？打开编辑器时看行序，最上面是最旧的提交。squash 的方向是“合并到上一个”，所以你想把fix: 修登录框样式合并进feat: 添加登录页面骨架里，后者必须排在前者的前面。

第二，rebase 过程中如果某一步冲突，Git 会停下来，提示当前处于 rebase 状态。你需要解决冲突、git add，然后git rebase --continue。如果中途发现整个方案不对，可以用git rebase --abort一次性退回执行前的状态。

第三，rebase 区间HEAD~5指的是从当前 HEAD 往上数 5 个提交。如果你不小心写成HEAD~1，那只会整理一个提交，没意义。想整理最近 N 条，确认 N 之前先git log --oneline -N看一眼列表。

5.3 黄金法则：什么时候绝对不能 rebase

业界有一个共识，被反复验证过的规则——不要对已经推送到远程、且其他团队成员可能拉取过的提交做 rebase。

原因是 rebase 会生成新的提交哈希，这让其他人本地保存的“旧分支指针”和新历史对不上。他们下一次 pull 时 Git 看到的不是“你新增了几个提交”，而是“历史被整个重写了”，于是开始尝试合并两个毫无关联的历史链，冲突如山倒，而且极难收拾。

什么时候可以放心 rebase？

• 提交只存在于本地，从未 push 过。
• 提交已经 push 到远程，但你百分之百确认该分支只有你自己在用（例如专属个人开发分支），且没有别的同事把分支拉走。
• 提交所在分支是一次性的、即将被删除的实验分支。

我见过最危险的一次事故：一个同事在共享的 develop 分支上执行了交互式 rebase，把过去两周的几十个提交压缩成了三个，然后强制推送。结果所有同事 pull 的时候都遇到了"fatal: refusing to merge unrelated histories"级别的冲突，最后大家只能各自保存未提交改动、删掉本地分支重新拉取。那天一个下午都耗在处理这场自己造成的历史灾难上。

所以在团队环境里，我需要强调一条实用经验：推送到远程之前，反复确认历史干净；推送到远程之后，默认不再对这条历史动刀。如果想清理远程分支历史，请走正规的合并策略（比如 merge 分支后使用 squash merge 保持主干干净），而不是事后 rebase 去擦屁股。

6. 常见问题排查与心得速查

最后把日常用得最多的排查场景和我的习惯动作整理成一个速查表，每一条都是我踩过坑换来的结论。

6.1 高频错误与解决方案速查表

6.2 我在实际项目中养成的五个 Git 习惯

这些习惯单个看起来微不足道，但组合起来会让整个团队的协作顺畅非常多。

第一个习惯：提交前运行git diff --check。它会检测空白字符错误，比如行尾空格、文件末尾缺换行符。很多 CI 或代码风格检查会因为这些细节报 failure，早发现早尴尬早解决。

第二个习惯：每个提交只做一件事。写代码的时候脑子里有“这个小修改属于另一个问题”的直觉时，不要犹豫，把它单独提交。哪怕多提交几次，也比一个提交里塞三件无关的事情好。回退和 revert 时，单一职责的提交让你能精确地撤销某一块变更而不会误伤其他功能。

第三个习惯：commit message 用 “类型: 描述” 的规范格式。feat:、fix:、docs:、chore:、refactor:这些前缀在生成 changelog 和回溯问题时能节省大量时间。描述用现在时祈使句，比如fix: 修复登录页面在移动端溢出问题，比fixed login overflow bug更符合 Git 官方的推荐习惯。

第四个习惯：push 之前先 rebase 保持同步。我在本地开发时经常拉取主分支的新提交，然后用git rebase把自己的小分支“搬到”最新代码上。只要还没推送，rebase 随便用；推送之前 rebase 一次，能让远程历史清晰很多。

第五个习惯：定期执行git fetch --prune并清理本地陈旧分支。远程分支被删除后，本地长期不动的分支引用会越来越多，卡顿倒是其次，主要会分散注意力——你其实根本不需要考虑那些已经死掉的功能分支。

6.3 最后分享一个救命的细节

不是每个问题都能靠命令解决，Git 的“后悔药”其实是有窗口的。本地被 reset 掉、rebase 掉的提交，只要在 reflog 里还有记录就能找回；但 reflog 不是永久保存的，默认过期时间是 90 天。如果某次操作之后隔了几个月才发现问题，那就真的找不回来了。

所以涉及到重要代码的操作，我的个人习惯是：任何大规模改写历史之前，先git branch backup-before-refactor打一个备份分支，或者直接git tag backup-20240115打一个轻量标签。这个动作只花两秒钟，但它能在你执行 rebase 到一半想放弃时，给你一个永远存在的保险丝。等确认新历史完全正确且稳定之后，再删掉备份标签。

写完这篇之后，我把这些命令整理成了一份“Git 操作速查卡”放在手边：reset 的三个模式背不过就查表、rebase 的金法则贴在终端旁边、每次要动共享分支之前把工具流程在心里默念一遍。工具这东西，用得越多，越知道什么时候该用哪个，什么时候绝对不能碰哪个。希望这篇从实战出发的拆解，能让你少走一些我当年走过的弯路。