弥勒鹿开头先讲个我碰到比较多的问题。隔一段时间就有人抱着一张打印出来的“Git 常用命令大全”来问，说自己背了大半个月，今天一用还是慌，要么不敢 push，要么 push 上去发现把不该提交的文件也交上去了。这种感觉我很理解，因为 Git 本来就不是靠背命令学会的工具。你说它命令多，其实你真正高频使用的就是 20 来个；但这些命令之间是有前后顺序和语义关系的，如果没把“为什么这样用”想明白，背再多命令列表，上手照样手足无措。
这篇东西我想换个角度写。不按命令字典的字母顺序给你罗列，而是按一条真实的工作流来拆：从初始化仓库、日常提交、分支合并，到同步协作、历史撤销，再到让 Git 更顺手的配置。每一条都是我实际在项目里反复用过、同时在团队辅导新人时被问过最多遍的操作。你可以把它当作“遇到某个场景时应该敲哪条命令”的速查手册，也可以跟着顺序读一遍，把散落的命令串成一条自己能跑通的主线。刚入门的读者建议从头到尾看，已经用了一段时间但总觉得心里没底的，可以挑自己薄弱的环节直接跳到对应章节。
1. 先弄懂仓库里的三个存放区，常用命令才不需要死背
1.1 工作区、暂存区和本地版本库，这套流向解释了一半命令
我遇到过不少朋友，git add 和 git commit 是会的，但你再问他“暂存区到底缓存了什么”“为什么提交前必须 add”，他就只能告诉你“大家都这么敲的”。这样用 Git，等于在盲人摸象。
其实 Git 的日常命令只需要围绕四个位置来理解：工作区（你当前编辑文件的目录）、暂存区（一个中间存放区，可以临时挑选下次要提交的内容）、本地版本库（已经提交的历史节点都存在这）、远程版本库（托管在服务器/GitLab/GitHub 上供团队共享的地方）。文件在正常情况下就在这几个位置之间流动：
| 命令动作 | 数据从哪到哪 | 一次典型的应用场景 |
|---|---|---|
git add |
工作区 -> 暂存区 | 我改了 README.md 和 index.js，只想把 README.md 放进下一次提交 |
git commit |
暂存区 -> 本地版本库 | 暂存区内容确认无误，生成一个新的本地历史节点 |
git push |
本地版本库 -> 远程版本库 | 把本地提交同步到远端，让大家看到 |
git fetch / git pull |
远程版本库 -> 本地 | 拉取队友已经推到远端的新提交 |
git checkout / git switch / git restore |
版本库中的某版本 -> 工作区 | 放弃当前工作区改动，把某个文件恢复成上一次提交状态 |
你可以把暂存区理解成购物车。逛超市看到好东西不一定要立刻付款，先在购物车里挑挑拣拣，确定这波真正想买单的再一起结账。add 就是往购物车里放东西，commit 才是刷卡拉出小票、成为永久历史记录。很多人以为提交代码是“一步到位”，其实 Git 刻意把它拆成了两步，目的就是给你一个每次提交前重新审视的机会：这 3 个文件该一起提交吗？那个 .env 环境变量文件刚才是不是手滑加进来了？
有个新人曾经很认真地问我：“那我永远直接 git add . 再 git commit，不也一样吗？”大多数随手项目确实能这样跑，但只要你开始跟别人协作，或者你的项目有关键配置文件不能泄露，你就会意识到问题：add . 会把当前目录下所有改动不分青红皂白全部放进购物车，等于放弃了 Git 最值钱的“精细控制”能力。关于这点，后面会在提交章节里展开。
1.2 查看类命令：动手改东西之前，一定要先知道仓库是什么状态
另一个新手习惯是“上来就闷头敲命令，敲完再看屏幕”。我的建议是反过来：动手前先把状态打听清楚。Git 里有一批命令不修改任何东西，只是帮助摸清现状，它们是整个工作流的地图。
git status：最常用的查看命令。它告诉你当前在哪个分支、工作区里有哪些文件被修改过、有哪些文件已经加入暂存区，以及远程分支有没有落后提醒。每次操作前敲一下，比事后出乱子再痛苦排查划算得多。git diff：查看还没add的那些改动，具体改了什么内容。如果你在status里看到一堆修改，不确定这些改动是否都是这次想提交的，用git diff看具体文本最直观。git diff --cached：查看已经add进暂存区的内容跟上一个提交之间的差异。这也是提交前的一步自查，下面会专门讲。git log：查看本地提交历史。我几乎每次落座写代码前都会先看两眼 log，回忆自己上一次做完了什么、这几次提交的节奏是否合理。后面要追查“这段代码是什么时候加的、为什么加”也靠它。git log --oneline --graph --decorate --all：以图形方式把最近提交和各分支指向关系打印成一行行的简略信息。当分支变多、流程图太长时，这一条是快速定位全局的利器。git show <commit-hash>：查看某一次具体提交改了什么文件、什么内容。配合 log 用，能把一段模糊记忆还原成清晰的 diff。
还有一个很容易踩坑的经验：别在一个完全陌生的仓库里直接敲消耗型命令。比如 git reset --hard、git clean -fd，它们会真的改掉文件。如果对仓库状态不了解，第一步永远是 git status。每次你准备对 Git 做“破坏性动作”（重置、清理、强推）前，先想一想：这个命令会改动文件吗？如果答案会，我有没有弄清楚当前状态？这比任何命令速查表都管用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 初始化与远端对接：从零开坑和交接项目，最容易出岔子的几个细节
2.1 git init 与 git clone，分别在什么时候用
当一个全新的项目刚刚创建好文件夹时，第一件事是往里跑 git init。它会在这个目录下生成一个隐藏的 .git 目录，所有 Git 历史、配置、引用都锁在这个目录里。此时