| 命令 | 分类 | 说明 | 示例 |
|---|
这里整理了 194 条 Git 命令，按使用场景分成 12 类，每条都给出了命令本身、所属场景、用途说明和一个可直接复制的示例。既适合刚开始用 Git 的新手按场景查找，也适合老手当作日常备查手册。
| 分类 | 数量 | 主要用途 |
|---|---|---|
| 仓库初始化 | 12 | init、clone、remote 配置 |
| 提交与修改 | 18 | add、commit、amend、签名 |
| 分支管理 | 20 | branch、checkout、switch、分支清理 |
| 远程协作 | 17 | fetch、pull、push、upstream |
| 撤销与回退 | 14 | reset、revert、restore、reflog |
| 暂存与清理 | 14 | stash、clean、忽略规则 |
| 查看历史 | 23 | log、diff、blame、bisect |
| 标签管理 | 10 | tag、release 相关 |
| 合并与变基 | 16 | merge、rebase、cherry-pick |
| 配置与别名 | 16 | config、alias、hooks |
| 子模块与工作树 | 12 | submodule、worktree、sparse-checkout |
| 高级技巧 | 22 | 性能、排错、仓库维护 |
工作区 / 暂存区 / 版本库。 Git 的文件有三种状态：工作区里改动的文件是「已修改」，git add 之后进入暂存区变成「已暂存」，git commit 之后才写入版本库成为「已提交」。绝大多数「我改了但提交没生效」的问题，都是漏了 add 这一步。
分支只是指针。 Git 的分支不是目录副本，而是一个指向某次提交的轻量指针。所以创建和切换分支几乎不耗时，HEAD 就是「当前你在哪个指针上」的标记。
提交是可寻址的完整快照。 每次提交都有唯一的 SHA-1 哈希，记录了当时整个项目的状态。只要提交还在，就永远可以回到那个状态——这正是 reflog 与 reset 能救命的原因。
| 命令 | 作用 | 注意 |
|---|---|---|
git commit --amend | 修改最近一次提交 | 已推送到远端的提交不要 amend，会造成历史分叉 |
git reset --hard | 丢弃工作区与暂存区改动 | 不可恢复，执行前先确认或用 git stash |
git rebase | 变基，整理提交历史 | 只对尚未推送的本地提交使用，已共享的分支禁止变基 |
git revert | 生成一个反向提交来撤销 | 安全，适合已推送的提交 |
git checkout -- . | 丢弃所有工作区改动 | 新版本推荐用 git restore .，语义更清晰 |
git push --force-with-lease | 强制推送但检查远端状态 | 比 --force 安全，能避免覆盖他人提交 |
rebase、撤销、stash；第一，多用 git status。 它几乎能回答你 80% 的疑问：当前在哪个分支、哪些文件改动了、哪些已暂存、有没有未推送的提交。
第二，动手前先建分支。 只要不在主分支上直接折腾，出错的代价就很小。哪怕只是一个实验，git switch -c try-xxx 也只是瞬间的事。
第三，遇到「完了」的时刻先别慌。 git reflog 会记录 HEAD 的每一次移动，绝大多数误操作（误 reset、误删分支、误 rebase）都能通过它找回。Git 里真正会丢数据的情况比想象中少得多。
新手最该先掌握哪些命令？
git bisect 是做什么的？
怎么临时保存当前改动去做别的事？
git push --force 和 --force-with-lease 有什么不同？
误删了分支怎么找回？
rebase 和 merge 有什么区别？
已经推送的提交要撤销，用 reset 还是 revert？
commit 之后想改提交信息怎么办？
git reset --hard 之后还能恢复吗？
改了文件但提交没生效，是什么原因？
Git 的三个区域分别是什么？
这个速查表收录了多少条命令？