封面

先说个让人安心的事实。Stack Overflow 是全世界最专业的程序员问答社区，它的「殿堂级问题」榜单上有一道题常年霸榜：《怎么撤销我刚才的 Git 提交？》——7500 多票、56 个回答，还被 ACM 期刊的研究列为 Git 类浏览量最高的问题。也就是说，全世界程序员看得最多的 Git 问题，是怎么反悔。

还有个更狠的：程序员圈流传最广的一幅漫画（xkcd #1597）教你 Git 出问题怎么办——把整个项目文件夹删掉，重新下载一份。这不是段子。我自己前几年就是这么干的，删目录重新 clone，还觉得挺高效。

连作者本人都没打算给它留面子。2005 年 4 月 7 日，Linus Torvalds 给 Git 打下第一个提交，提交说明里他给这个东西起的外号是：「来自地狱的信息管理器」。

你不是一个人：全世界都在搜「怎么撤销提交」

一个 93.87% 的开发者天天在用的工具（Stack Overflow 2022 年开发者调查），为什么用了很多年还是心虚？我的答案是一句话：因为你一直在背命令，而 Git 其实是一张地图。命令背不完，地图只有一张。

一张地图：四个盒子 + 一份清单

Git 全景地图（招牌图）

把写代码想成往公司总仓发货。Git 里所有让你头大的名词，其实就是四个盒子：工作区是你的书桌，代码改来改去都在这；git add 把改好的东西放上打包台（暂存区）；git commit 封箱贴单、存进自家仓库（本地仓库），每个箱子就是一次提交；git push 发货到公司总仓（远程仓库，比如 GitHub）。

真正的关键是图里那个金色虚线框——origin/main。它不是远程分支本身，而是你本地存的一份「远端快照」，像贴在你家墙上的总仓库存清单，写的是你上次同步时总仓的样子。同事这一小时推了十个提交？你墙上的清单不会自己变，只有 fetch 一下才更新。我见过的关于 pull、fetch 的困惑，九成都是因为不知道这个「第五个盒子」的存在。

fetch 和 pull：抄清单，还是直接搬货

三个位置，谁动了

git fetch：去总仓抄一份最新清单贴回墙上。你的代码一个字都不会动，所以绝对安全，随便敲。

git pull：抄完清单，顺手按清单把新货全搬进你家，等于 fetch + merge 连招。方便，但新货和你正在改的东西打架，冲突当场爆在你脸上。

所以老手的习惯是分两步：先 git fetch，再用 git log HEAD..origin/main 看看对面来了什么，心里有数了再合。我是被同事的强制推送坑过一次之后养成的这个习惯——重要的仓库，一律先抄清单看一眼。顺手升个级：git config --global pull.rebase true，以后 pull 自动走 rebase，历史干净一条线。

merge 和 rebase：打个结，还是搬个家

同一个分叉，两种收尾

场景摆具体：你从 main 拉了分支，提交了 A、B；这期间同事往 main 合了 C。现在要把 C 拿进来，两条路——

merge（打结）：新造一个「合并提交」把两条线拧上。你的 A、B、同事的 C 谁都没被动过，历史里永远查得到「这里分过叉」。代价是结点越攒越多，项目大了提交图像蜘蛛网。

rebase（搬家）：把你的 A、B 摘下来，接到 C 后面原样重放成 A′、B′。历史变成一条直线，像你从头就在最新代码上写的。但注意：A′ 和 A 只是内容一样，提交号是全新的——旧提交被销毁重造，这就是「改历史」的确切意思。

怎么选：就问一个问题

怎么选，就问一个问题：这条分支除了我还有别人在用吗？没有，rebase，给自己留条干净直线；有，merge，谁的提交都别动。为什么共用分支碰不得 rebase：你把 A、B 重造成 A′、B′ 推上去，同事电脑里还揣着旧的，他一同步，两套「长得一样的提交」当场撞车，全组历史对不上。记一句话就够：自己的分支随便搬家，大家的分支只打结。

为什么设计得这么难？它本来就不是为你设计的

它本来就不是为你设计的

因为 Git 是一场十天的救火。2005 年 4 月，Linux 内核团队用的商业版本管理工具 BitKeeper 撤回了免费授权，Linus 4 月 3 日动工、4 月 7 日 Git 就开始用 Git 管理自己。十天里他要的是三样东西：快、分布式、数据绝不丢。用户是全世界最硬核的几百个内核开发者，「对新手友好」从头到尾没进过需求清单。

你觉得难的每一处，几乎都是「分布式」的代价：每个人电脑里都有一份完整仓库，才会有本地分支、远程分支、远程跟踪分支三套概念。连官方术语都承认界面是二等公民：底层命令叫 plumbing（管道），给人用的壳叫 porcelain（瓷件，就是马桶那个瓷）。checkout 一个词干三种活，拖到 2019 年才拆出 switch 和 restore。所以记不住命令真不丢人——一个为内核黑客设计的系统，被全世界当成了入门必修课。

公司仓库那四种分支：feature / hotfix / develop / master

四种分支角色 + tag 图钉

master 是正品货架，永远摆着随时能发的版本；develop 是组装车间；feature 一个活一条流水线；hotfix 是紧急维修通道——线上炸了从货架直接切出来修，修完必须同时合回 master 和 develop，不然下次发布把老 bug 原样再发一遍。这套叫 Git Flow，2010 年提出。连作者本人 2020 年都补了按语：持续上线的纯 Web 项目别硬套，一条 main 加 feature 分支就够；有版本号要维护的产品，这套才值得。

tag 什么时候打：发布必打，平时不打

tag 三件套

tag 的答案很干脆：对外发布必打，日常提交不打。分支是会动的便签，tag 是钉死的图钉。打法是 git tag -a v1.2.0 -m "说明"，版本号三段=主版本.新功能.修 bug。最容易踩的坑：git push 默认不推 tag，要单独 git push origin v1.2.0，不然 tag 只活在你电脑上。回报在哪？线上出事，git switch --detach v1.1.0 一步回到那个版本的完整代码；CI 也普遍靠 tag 触发自动打包发版。

高频翻车现场①：写了半天，发现在错误分支上

stash 三连救场

写了半天代码，一看分支名——在 master 上。只要还没 commit，三连就能救：git stash（改动收进抽屉）→ git switch -c 新分支（换到正确工位，没有就现建）→ git stash pop（取出来接着写）。pop 和 apply 的区别一句话：pop 取完抽屉就空了，apply 取完单据还留着——怕合出冲突想留个底，就用 apply，确认没事再 drop。已经 commit 了也有解：到正确分支 git cherry-pick 那个提交号，再回原分支 git reset --hard HEAD~1 退掉（这里的 --hard 删的是已经搬走的提交，动手前想三秒）。

高频翻车现场②：origin 不是关键字，只是备注名

多远程三步

很多人以为 origin 是 Git 的关键字，其实它只是 clone 时给远程仓库起的默认备注名。git remote add gitee 地址 就能加第二个远程，推拉都可以点名：git push gitee main、git fetch gitee。想一条 push 同时发两个仓（GitHub + Gitee 镜像），给 origin 追加推送地址即可——注意先把原地址用 git remote set-url --add --push 加回去，再加镜像地址，顺序反了就只推镜像不推主仓。同步铁律只有一条：只认一个主仓，其余全是只写镜像。

2026 年学 Git，性价比反而变高了

Git 成了 AI 的安全网

最后说个反直觉的：都 AI 写代码了，Git 是不是可以少学点？恰恰相反。AI 编程工具（比如 Claude Code）跑多个并行会话的推荐做法，就是给每个会话开一个独立的 git worktree（一个仓库多个工位），2015 年的冷门功能十年后成了 AI 编程的基础设施。更重要的是，Git 从「协作工具」变成了「你敢不敢放手让 AI 改代码」的底气：commit 越勤，AI 能闯的祸越小，每个提交都是存档点。我现在让 AI 放手改代码只有一个前提：git status 是干净的。

最后：一张速查表，按「想干什么」查

场景→命令速查表（建议截图收藏）

这张表按「我想干什么」排，不用背：看远端更新、同步进度、撤销提交、改提交说明、换分支、丢改动、发错分支救场、同时干两个活、推第二个远程、查谁写的代码——九个高频场景各一条命令。特别记住 reset 的三档里只有 --hard 真会删你写的代码，敲之前想三秒。

金句 + 预告

Git 难，是因为你在背命令。看懂地图之后，每条命令都只是地图上的一支箭头。

你被 Git 坑得最惨的一次是什么？是删过库、rebase 崩过、还是 push --force 干掉过同事的代码？评论区聊聊，我看看有多少难兄难弟。

（资料来源：GitHub Blog 二十周年 Linus 访谈、Git 2.5 / 2.23 发布说明、Stack Overflow 2022 开发者调查、ACM TOSEM 期刊研究、nvie.com《一个成功的 Git 分支模型》及作者 2020 年按语、Claude Code 官方文档。关键年份与数据均逐条核实。）