你并不需要背下几十条 Git 命令，才能把日常开发做好。大多数工作其实只围绕六件事：看清改动、精确暂存、清晰提交、安全切分分支、同步远端，以及在出错时不要把事情变得更糟。现代 Git 还把旧的 checkout 拆成了 switch 和 restore，可读性比以前更好。
目标与前提
这篇文章不是追求“大而全”的速查表，而是想给你一套稳定、够用的日常命令集合。
默认你已经有：
- 已安装的 Git，
- 一个正在工作的仓库，
- 以及一个基础概念：Git 主要围绕 工作区、暂存区 和 提交历史 运作。
简短答案
如果下面这些命令你都用熟了，绝大多数日常工作就能覆盖：
git statusgit diffgit add和git add -pgit commitgit switchgit restoregit fetch和git pullgit reset和git revertgit stash
逐步操作流程
1. 动手前先看清状态
git status
git diff
git diff --staged
status 先告诉你哪些文件改了；diff 看未暂存改动；diff --staged 看下一次提交真正会包含什么。
2. 精确暂存，不要习惯性一把梭
git add path/to/file
git add -p
整文件都属于同一个改动时，用普通 git add 就够了；如果同一个文件里混了几类修改，git add -p 更适合拆分提交。
3. 一次提交只表达一个清晰意图
git commit -m "Explain what changed"
好的提交说明是解释“做成了什么”，而不是“文件有变化”。如果你发现暂存区里混进了不该进来的内容，先修正暂存区，再提交。
4. 用现代命令创建和切换分支
git switch -c feature/name
git switch main
git switch 更适合表达“切换分支”这个动作，-c 表示创建并切换。
5. 用 restore 做文件级撤销
git restore path/to/file
git restore --staged path/to/file
git restore 适合做文件级回退：
- 不带
--staged时，恢复工作区副本； - 带
--staged时，把文件从暂存区拿出来。
这通常比记忆旧式 checkout -- <file> 更直观。
6. 同步远端时先分清 fetch 和 pull
git fetch origin
git pull --rebase
fetch 只下载远端更新，不会直接改你当前分支；pull 则会下载并整合。很多团队更喜欢 pull --rebase 来保持历史更线性，但最终还是要遵守你所在项目的协作约定。
7. 选对撤销方式
git reset --soft HEAD~1
git reset --mixed HEAD~1
git revert <commit>
这三种用途不同：
reset --soft：把HEAD往回挪，但保留已暂存状态；reset --mixed：把HEAD往回挪，并把修改放回工作区；revert：新增一个“反向提交”去抵消旧提交，适合共享分支。
git reset --hard 只有在你确定本地改动可以直接丢弃时才应该用。
8. 任务临时切换时再用 stash
git stash push -m "wip"
git stash list
git stash apply
stash 更像短期置物架，而不是长期仓库。它适合临时切任务，不适合把半成品长期藏起来。
常见失误与更稳妥的替代做法
我直接 pull 了，但其实还没看远端发生了什么
更稳妥的做法：先 git fetch，看完再整合。
我只想丢掉一个文件的改动，不想重写历史
优先用 git restore，不要上来就大范围 reset。
我要撤销的是已经推送出去的提交
优先考虑 git revert，不要轻易用 reset 去改共享历史。
一个文件里混进了两类无关修改
用 git add -p 把提交拆干净。
我还在用 checkout 包打天下
现代 Git 之所以提供 switch 和 restore，就是为了把“切分支”和“恢复文件”这两件事分开表达。
检查清单
- 重要命令前后我都会先看
git status。 - 我会先看 diff，再决定暂存哪些内容。
- 我用
switch管分支，用restore做文件回退。 - 共享历史上优先用
revert。 -
stash只用于短期任务切换。
来源与更新时间
本文命令行为和示例于 2026 年 7 月 18 日 对照官方 Git 文档完成核对。Git 会持续演进，但遇到团队流程或版本差异时，上面的官方命令页仍然是最可靠的依据。