危险等级#

• 低：几乎不会改坏东西
• 中：会改变分支状态、远程状态或合并历史，需要看清楚再敲
• 高：可能覆盖历史、丢改动、影响队友

常用指数#

这是按日常团队开发里的主观实用度打的，不是官方排名。

• ★★★★★：几乎天天会用
• ★★★★☆：非常常用
• ★★★☆☆：比较常用，但不是每次都用
• ★★☆☆☆：场景性很强

场景 1：提交前先确认#

你改完代码之后，不要急着提交，先 gst 看一眼。

场景 2：切分支前确认工作区是否干净#

切分支、rebase、merge 前，先看有没有没处理的改动。

场景 3：推送前确认有没有漏提交#

你以为自己都提交完了，gst 一看还有没 add 的东西。

例子 A：开发完准备提交#

1
gst

你看到：

• modified: src/login.ts
• modified: src/api.ts

说明你改了两个文件，但还没暂存。

例子 B：你准备推送#

1
gst

看到：

• Your branch is ahead of 'origin/feat/login' by 2 commits

这就说明你本地有 2 个提交还没推上去。

1. gst 不会修任何问题#

它只负责“告诉你发生了什么”。

2. 一切危险操作前都先跑一次 gst#

尤其是：

• grb
• gm
• gl
• gpf
• grh

3. 小白最容易忽略的一点#

很多人“以为自己知道当前状态”，结果其实不知道。gst 就是防止这种自信翻车的第一道保险。

用法 1：切换分支#

1
gco main

意思：切到 main 分支。

用法 2：恢复某个文件#

1
gco -- src/login.ts

意思：把这个文件恢复成当前提交里的版本，丢掉你在工作区的改动。

这第二种用法很危险。

gco <branch>#

切换到某个已存在分支。

例子：

1
gco develop

gco -b <new-branch>#

创建并切换到新分支。

例子：

1
gco -b feat/user-center

不过在 oh-my-zsh 里通常更常写成：

1
gcb feat/user-center

gco -- <file>#

恢复单个文件到当前提交版本。

例子：

1
gco -- package.json

gco <commit> -- <file>#

从某个历史提交里拿回一个文件版本。

例子：

1
gco a1b2c3d -- src/config.ts

场景 1：切到主分支拉最新代码#

1
gco main
2
gl

场景 2：切回自己的功能分支继续开发#

1
gco feat/login-refactor

场景 3：某个文件改乱了，想撤回#

1
gco -- src/login.ts

例子 A：你要开始新功能#

1
gco main
2
gl
3
gco -b feat/payment-page

意思是：

1. 切到主分支
2. 拉最新代码
3. 基于最新主分支开一个新功能分支

例子 B：你误改了一个文件#

1
gst
2
gco -- src/mock.ts
3
gst

恢复后再看状态，就会发现这个文件不再显示修改。

1. gco -- 文件名 会直接丢掉你没提交的修改#

如果你还想留着，就别直接用。

2. 现在新手更建议学 git switch 和 git restore#

因为语义更清楚，不容易混。

3. 切分支失败时，通常不是 Git 坏了#

大概率是：

• 你有未提交改动
• 目标分支不存在
• 你当前改动会和目标分支冲突

1. 同步主分支最新代码#

你的功能分支开发了一半，主分支已经前进了。你可以把自己的分支 rebase 到最新主分支上。

2. 整理提交历史#

把历史弄得更直、更干净，方便 review。

用法 1：把当前分支 rebase 到 main#

1
grb main

用法 2：把当前分支 rebase 到最新远程主分支#

1
grb origin/main

用法 3：交互式 rebase#

1
grbi HEAD~3

意思：整理最近 3 个提交。

grb <branch>#

把当前分支变基到某个分支上。

grbi#

对应：

1
git rebase --interactive

作用：交互式编辑提交历史。

grba#

对应：

1
git rebase --abort

作用：rebase 出问题了，放弃本次 rebase。

grbc#

对应：

1
git rebase --continue

作用：解决冲突后继续。

grbs#

对应：

1
git rebase --skip

作用：跳过当前这个冲突提交。

场景 1：提 PR 前同步主分支#

1
gco main
2
gl
3
gco feat/login
4
grb main

场景 2：让提交历史更干净#

你做了 5 个零碎提交，准备合并前用交互式 rebase 整理。

场景 3：团队要求“不要 merge main，统一 rebase main”#

很多团队会有这种规范。

例子 A：同步主分支最新提交#

你在 feat/login 分支上开发两天了，这两天 main 又进了很多提交。

你做：

1
gco main
2
gl
3
gco feat/login
4
grb main

结果：

• 你的功能分支看起来像是基于最新 main 开始写的
• 历史通常会比 merge 更直

例子 B：rebase 过程中冲突#

1
grb main

报冲突了。

你需要：

1. 打开冲突文件解决冲突
2. git add 把冲突解决结果标记好
3. 运行：

1
grbc

如果你不想继续了：

1
grba

1. rebase 本质上是在“改写提交历史”#

这意味着同一段改动会生成新的提交 ID。

2. 已经推送给团队、别人也在基于它工作的分支，不要轻易 rebase 后强推#

否则别人会很痛苦。

3. 小白的基本原则#

• 自己本地分支：可以 rebase
• 团队共享分支：慎重 rebase

4. rebase 不是更高级的 merge#

它只是另一种整合历史的方法，没有绝对谁更高级。

用法 1：把主分支合进当前功能分支#

1
gm main

用法 2：把功能分支合进主分支#

1
gco main
2
gm feat/login

gm <branch>#

合并指定分支到当前分支。

gma#

对应：

1
git merge --abort

合并冲突时，放弃这次 merge。

gmc#

对应：

1
git merge --continue

解决冲突后继续。

gms#

对应：

1
git merge --squash

把对方分支的多个提交压成一个待提交改动。

gmff#

对应：

1
git merge --ff-only

只允许快进合并，不允许产生 merge commit。

merge#

• 不改已有提交历史
• 会把分支合并痕迹保留下来
• 更适合保留真实开发轨迹

rebase#

• 改写当前分支提交历史
• 历史更直
• 更适合整理后再合并

场景 1：你想保留真实合并关系#

那就用 merge。

场景 2：团队不要求线性历史#

merge 很正常。

场景 3：把 main 合进功能分支解决兼容问题#

1
gco feat/order
2
gm main

例子 A：把主分支最新改动并进功能分支#

1
gco main
2
gl
3
gco feat/payment
4
gm main

这样做完后，你的功能分支就包含主分支最新改动。

例子 B：merge 冲突处理#

1
gm main

冲突了。

你需要：

1. 编辑冲突文件
2. git add 标记冲突已解决
3. 如果 Git 要求继续：

1
gmc

不想继续：

1
gma

1. merge 不等于安全无脑#

它虽然不改历史，但照样会产生冲突。

2. 你当前站在哪个分支，非常重要#

gm xxx 的意思是：把 xxx 合进当前分支。

很多人会把方向搞反。

3. 小白口诀#

先 gst，再看自己站在哪个分支，再 merge。

用法 1：更新主分支#

1
gco main
2
gl

用法 2：更新你当前分支对应的远程分支#

1
gco feat/login
2
gl

gl#

默认 pull。

gpr#

对应：

1
git pull --rebase

作用：拉取后用 rebase 方式整合，而不是 merge。

gpra#

对应：

1
git pull --rebase --autostash

作用：有未提交改动时，先自动 stash，再 pull rebase，最后恢复改动。

ggpull#

对应：

1
git pull origin 当前分支

更明确地拉当前分支的远程对应分支。

场景 1：每天开工先更新主分支#

1
gco main
2
gl

场景 2：切回老分支前先同步#

1
gco feat/profile
2
gl

场景 3：你准备 rebase 前，先把主分支拉到最新#

1
gco main
2
gl
3
gco feat/order
4
grb main

例子 A：早上第一件事#

1
gco main
2
gl

这是很典型的日常动作。

例子 B：pull 出现冲突#

说明远程更新和你本地提交/改动发生了冲突，需要你手动解决。

1. gl 不是“只下载”#

它是下载 + 整合。

如果你只想下载不合并，用的是：

1
gf

2. 工作区不干净时直接 gl，更容易冲突#

先 gst。

3. 团队如果偏好线性历史，可能更推荐你用 gpr#

也就是 pull 后 rebase。

用法 1：把当前分支推上去#

1
gp

前提是当前分支已经有 upstream（上游分支）配置。

用法 2：新分支第一次推送#

通常你会用：

1
gpsup

意思是第一次推送并建立跟踪关系。

gp#

普通推送。

gpd#

对应：

1
git push --dry-run

先演练，不真正推。

gpv#

对应：

1
git push --verbose

更详细输出。

ggp#

对应：

1
git push origin 当前分支

显式推当前分支到 origin。

场景 1：本地提交后推上去备份#

1
gp

场景 2：推上去让 CI 跑起来#

很多团队 push 后自动触发构建、测试、部署检查。

场景 3：推上去开 PR#

推送是开 PR 前的前置动作。

例子 A：你刚做完一轮提交#

1
gst
2
gp

例子 B：第一次推分支#

1
gco -b feat/refactor-header
2
# 开发、提交以后
3
gpsup

1. gp 只能推“提交”，不能推你还没 commit 的工作区改动#

很多小白以为 push 会把所有改动一起传上去，不会。

2. push 失败很常见，不一定是你出错#

常见原因：

• 远程有新提交，你本地落后了
• 没有权限
• 当前分支没配置 upstream
• 钩子检查没过

3. 推之前最好看一眼 gst#

确认没有一堆你以为已经提交、其实还躺在工作区里的改动。

gpf!#

相当于：

1
git push --force

它比较蛮横。

gpf#

相当于：

1
git push --force-with-lease

它会先确认远程分支没有被别人偷偷推进新内容。

所以它比纯 --force 更安全。

--force-with-lease#

如果远程分支状态不是你以为的那个状态，就拒绝强推。

--force-if-includes#

在较新 Git 中进一步约束强推条件，降低误覆盖风险。

场景 1：你 rebase 过自己的功能分支#

1
grb main
2
gpf

场景 2：你 amend 了最近一次提交#

1
git commit --amend
2
gpf

场景 3：你用交互式 rebase 把 5 个提交压成 1 个#

1
grbi HEAD~5
2
gpf

例子 A：你自己的功能分支，自己在维护#

1
gco feat/login
2
grb main
3
gpf

这是相对常见且合理的用法。

例子 B：共享分支乱强推#

如果某个分支是多人一起推的，你 gpf 可能直接把别人的历史覆盖掉。

1. gpf 不是日常 push 替代品#

只有在“历史被你改写过”的时候才考虑它。

2. 能不用强推，就别用#

尤其不要把强推当日常习惯。

3. 最适合 gpf 的地方#

• 你自己的个人功能分支
• 还没被别人基于它开发
• 你明确知道自己刚刚 rebase / amend 过

4. 不适合 gpf 的地方#

• 公共主分支
• 多人共享开发分支
• 你并不确定远程发生过什么

1. grh <commit>#

1
git reset <commit>

作用：把当前分支指针移到某个提交，通常也会重置暂存区，但保留工作区改动。

2. grhs <commit>#

1
git reset --soft <commit>

作用：回退提交，但保留暂存区和工作区。

适合：

• 想撤销提交
• 但想把改动继续保留下来重新提交

3. grh / gru <file>#

常用于取消暂存。

例子：

1
git add src/login.ts
2
gru src/login.ts

意思：把这个文件从暂存区拿下来。

4. grhh <commit>#

1
git reset --hard <commit>

作用：回退提交、重置暂存区、连工作区也一起回退。

这个非常危险。

场景 1：你 add 多了，想取消暂存#

1
gru src/login.ts

场景 2：你刚提交，想把提交撤回但保留改动#

1
grhs HEAD~1

场景 3：你本地改乱了，想彻底回到某个提交#

1
grhh HEAD

或

1
grhh origin/main

例子 A：撤销最近一次提交，但保留改动#

1
grhs HEAD~1

结果：

• 最近一次 commit 没了
• 改动还在
• 暂存区状态也还在

例子 B：取消暂存某个文件#

1
git add src/a.ts src/b.ts
2
gru src/b.ts

结果：

• src/a.ts 还在暂存区
• src/b.ts 被拿回工作区

例子 C：硬回退#

1
grhh HEAD~1

结果：

• 最近一次提交没了
• 相关工作区改动也没了

1. 小白最常用、最该先会的是：取消暂存#

也就是类似：

1
gru 文件名

2. --soft 比 --hard 安全很多#

• --soft：保留改动
• --hard：可能直接清空改动

3. reset 和 revert 不是一回事#

• reset：改你的本地历史指针
• revert：新建一个“反向提交”去抵消旧提交

4. 已经推送共享出去的历史，不要随便 reset 后再强推#

因为最后往往会演变成你要 gpf，然后影响别人。