Git与GitHub零基础入门：版本控制、仓库推送与报错排查

第一次点开 GitHub 首页的人，十个里有八个会先愣上几秒：满屏英文、一排看不懂的按钮、右边还挂着一串像乱码的版本号。很多人就是在这一步退出去的，觉得自己"不是这块料"。其实 GitHub 新手阶段真正需要掌握的东西非常少，大概就是六个动作加上几次踩坑，剩下的都是在这几个动作上叠细节。这篇内容就是把我带过好几批新人的经验整理出来，讲讲一个完全没接触过版本管理的人，怎么在一周内把 GitHub 用到"日常不慌"的程度。

先把定位说清楚：GitHub 是一个代码托管平台，它本身不负责管理版本，真正干活的是装在你电脑上的 Git。这两个东西的关系，很多教程一上来就混着讲，导致新手以为"注册了账号就等于会用 Git 了"，结果本地装没装 Git 都不知道。这篇会按"先分清角色、再跑通链路、最后处理异常"的顺序推进，适合完全零基础的人从头照着做，也适合用过几次但一直半懂不懂的人补课。下面所有命令都以主流桌面系统为准，Windows、macOS、Linux 的思路一致，差异我会单独点出来。

1. 先分清三样东西：GitHub、Git、还有你电脑上那个文件夹

新手最容易混乱的地方，是把"平台账号"和"本地工具"当成一回事。我见过不少人，网页上建好了仓库，就以为本地的代码自动同步上去了，然后关掉浏览器去找，发现本地什么都没有。所以动手之前，先把三个角色摆清楚，后面所有操作都能对上号。

1.1 账号、远程仓库、本地目录各自的角色

打个比方：Git 是记账本，GitHub 是保险柜，你电脑上的项目文件夹是办公桌。

Git装在本地，负责记录"谁在什么时候改了哪一行"。它会在你的项目目录下生成一个隐藏的.git文件夹，所有历史版本都躺在里面。这个文件夹删了，历史就没了，文件本身还在，但变成了"没有记账的普通文件"。

GitHub 上的仓库（repository）是远程的一份副本，它承担两个作用：备份和协作。它的地址长这样：https://github.com/用户名/仓库名.git。

本地目录就是你在文件管理器里能看到的那些文件。注意，一个目录只有执行过git init或者git clone之后，才和 Git 产生关系，否则它只是个普通文件夹。

三者的数据流向是：本地改文件 →git add送到暂存区 →git commit存进本地仓库 →git push推到 GitHub。反过来，别人改了远程，你要git pull拉回本地。这条链路是后面所有内容的主干，记不住命令没关系，记住方向就行。

1.2 第一次配置：邮箱、用户名、默认分支

装完 Git 之后，第一件事不是建仓库，是配置身份。Git 每次提交都会把你的名字和邮箱写进历史，这不是可选项。

git config --global user.name "你的昵称" git config --global user.email "你的邮箱" git config --global init.defaultBranch main

第三条是设默认分支名。老版本 Git 默认叫master，现在主流平台默认叫main。如果不统一，你会遇到"本地推上去多出一个分支"的怪事。我建议直接把默认改成main，省得后面来回改。

检查配置是否生效：

git config --global --list

提示：--global表示对当前用户所有仓库生效。如果你某台机器上有多个身份（比如个人项目和工作项目分开），可以在具体仓库里不加--global再配一次，仓库级配置优先级更高。

还有一个容易忽略的点：邮箱最好和你 GitHub 账号绑定的邮箱一致，否则提交记录在网页上不会关联到你的头像，显示的是一个灰色的默认图标。这不影响功能，但看起来很像"不知道从哪冒出来的提交"，协作时别人不好找到你。

1.3 HTTPS 还是 SSH：两条认证路线的取舍

把本地代码推到 GitHub，得先证明"你是你"。两条路：

SSH 的配置步骤：

ssh-keygen -t ed25519 -C "你的邮箱" # 一路回车，默认存到 ~/.ssh/id_ed25519 cat ~/.ssh/id_ed25519.pub

把输出的那一整行（以ssh-ed25519开头）复制，粘贴到 GitHub 网页的 Settings → SSH and GPG keys → New SSH key。然后测试：

ssh -T git@github.com

看到successfully authenticated就成了。

HTTPS 路线则是去 Settings → Developer settings → Personal access tokens 生成一个令牌，推送时把令牌当密码填。令牌只显示一次，关掉页面就再也看不到了，务必当场保存。

我个人的建议是：如果你打算长期用，一次麻烦换长期省事，直接上 SSH。如果只是在别人电脑上临时拉个东西看看，HTTPS 更省事。

2. 建仓库这件小事，藏着新手最容易踩的坑

建仓库看起来就是点一个绿色按钮，但页面上那几个勾选项，每一个都在影响你后面能不能顺利推送。我带新人的时候，十次"推不上去"里有六次问题出在这一步。

2.1 网页端 New repository 那四个勾选项在做什么

点右上角加号 → New repository，会看到仓库名、描述、公开/私有，以及几个勾选项。逐个说：

仓库名：建议全小写、用短横线分隔，不要用中文和空格。虽然现在也能跑，但在命令行里输入中文路径会带来一堆麻烦，尤其是在不同终端里编码不一致的时候。

Public / Private：公开仓库任何人可见，私有仓库只有你和被邀请的协作者可见。新手练习建议先用私有，等东西成型了再考虑公开。

Add a README file：README 是仓库的"首页说明"。勾了它，仓库创建出来时就已经有一次提交，不会是一个空壳。这个选项很关键：如果勾了，你在本地就不能直接git init然后推，得先clone下来再往里加东西，否则两条互不相关的历史线会撞车。

Add .gitignore：选一个模板，会自动帮你排除不该进仓库的文件。后面第 6 节会细说。

Choose a license：开源协议。自己练手的私人项目可以先不选。

新手最常见的错误是：网页上勾了 README，本地又git init建了一遍，然后git push时报rejected (fetch first)。原因就是两边的历史没有任何共同祖先，Git 拒绝合并。

2.2 本地已有代码怎么推上去：一条完整命令链

假设你本地已经有一个写好的项目，想推到刚建好的空仓库（建仓库时不要勾 README、不要勾 .gitignore，保持完全空仓）。

cd 你的项目目录 git init git add . git commit -m "chore: 初始化项目" git remote add origin git@github.com:用户名/仓库名.git git branch -M main git push -u origin main

逐条解释为什么这么写：

git init在目录里创建.git，此时目录变成"被 Git 管理的仓库"。

git add .把当前目录下所有变化放进暂存区。注意那个点代表"当前目录及子目录"，别在错误的层级执行。

git commit -m生成一次快照，-m后面是说明。这是必填的，不写会弹出一个编辑器让你写，新手经常卡在这个界面不知道按什么退出（提示：vi 系编辑器按Esc，输入:wq回车）。

git remote add origin建立"远程地址的别名"。以后不用每次敲完整地址，用origin代替即可。一个仓库可以有多个 remote，但新手只会用到 origin。

git branch -M main强制把当前分支改名成 main。-M是大写，表示"即使已存在也强制改名"。

git push -u origin main推送到远程，-u把本地分支和远程分支绑定。绑定之后，以后只需要敲git push，不用再带后面那一串。这一步很多人漏掉-u，然后每次都手打全称，其实没必要。

2.3 clone 下来之后为什么"跑不起来"

新手从网上 clone 一个项目，最容易出的问题不是 Git 错，而是项目本身跑不起来。常见原因有三类：

缺依赖。仓库里通常只有源码，没有node_modules、venv这类依赖目录（因为它们本来就不该进仓库）。拉下来之后得按 README 的说明装依赖，比如npm install或pip install -r requirements.txt。

缺配置。数据库密码、接口地址这类东西一般放在.env之类的文件里，而这类文件通常被.gitignore排除了。所以你得自己复制一份模板，比如cp .env.example .env，再填上本地环境的值。

缺大文件。有些项目用 Git LFS 存放大文件，没装 LFS 的话拉下来是一堆指针文本。这时候需要先装 LFS 再git lfs pull。

提示：clone 之后第一件事永远是把 README 从头到尾读一遍。我见过太多人跳过 README 直接跑命令，然后卡在一个已经被写清楚的坑里。

3. 日常操作其实只有四个动作：改、加、提交、推

跑通第一次推送之后，后面 90% 的时间你只会在重复四个动作。把它练到肌肉记忆，GitHub 就不再可怕了。

3.1 暂存区是干什么用的，为什么不能跳过

git add这一步很多人觉得多余——我改完文件直接提交不就行了？暂存区（staging area）的存在，是为了让你精确控制这次提交包含哪些改动。

真实场景是这样的：你在写一个功能，顺手把另一个模块的注释也改了两行，还顺手删了一个调试语句。如果一股脑全提交，这条提交记录就变成了大杂烩，将来查问题时看到它只会更困惑。有了暂存区，你可以只把功能相关的文件加进去，其他改动留在工作区。

常用命令：

git status # 看当前哪些文件变了 git add 文件名 # 加单个文件 git add . # 加当前目录所有变化 git restore --staged 文件名 # 从暂存区撤回（还没提交） git restore 文件名 # 丢弃工作区的修改（危险，不可恢复） git diff # 看工作区改了什么 git diff --staged # 看暂存区里改了什么

git status是使用频率最高的命令，没有之一。养成"动手前后各敲一次"的习惯，能省掉一大半的误操作。它会告诉你：当前在哪个分支、有哪些已暂存、哪些未暂存、哪些是未跟踪的新文件。

3.2 提交信息写不好，三个月后自己都想骂人

提交信息是给未来的自己看的。我翻自己两年前的仓库，看到一堆update、fix bug、改了一下，完全想不起来当时改了什么，只能一行行看 diff。这种成本是复利的，越往后越痛。

一个够用的写法是"类型: 做了什么"，常见类型：

例子：fix: 修复分页参数在第二页失效的问题。前半句说清类型，后半句说清现象，一看就懂。

再进一步，标题控制在 50 个字符以内，需要展开说明的，空一行写正文。这个规则来自社区长期形成的习惯，不是硬性规定，但遵守它能让git log --oneline的输出非常清爽。

git log --oneline --graph

这条命令会把提交历史画成树状，分支和合并一目了然。新手阶段多看看这个，能建立起"提交是一串快照"的直觉。

3.3 push 被拒绝：non-fast-forward 的完整排查链路

这是新手遇到的第一个真正让人慌的报错：

! [rejected] main -> main (non-fast-forward) error: failed to push some refs to ...

它的意思是：远程仓库上有你本地没有的提交，Git 不敢直接覆盖你。原因通常是两种：你在网页上直接改了文件，或者有别人往这个仓库推了东西。

排查顺序，照着走：

第一步，先看清楚差异。

git fetch origin git log --oneline --graph main origin/main

这一步能看到本地和远程各自多出来的提交。如果是网页上改的 README，你会看到一条只有远程有的记录。

第二步，判断取舍。三种处理方式：

# 方式一：先拉再推（推荐，会保留双方历史） git pull origin main --rebase git push # 方式二：直接拉，产生一次合并提交 git pull origin main git push # 方式三：确认远程内容不重要，强制覆盖（危险） git push --force-with-lease

方式一用--rebase，会把你的本地提交"挪到"远程提交之后，历史是一条直线，干净。方式二会产生一个合并节点，历史有分叉，但对新手更安全，不会出现意外。方式三只在"远程那条提交确实是我不要的"时候用，而且永远用--force-with-lease而不是--force：前者会在远程有别人的新提交时拒绝执行，后者是无条件覆盖，一旦把同事的代码盖掉，恢复起来很难。

注意：--force类操作在团队仓库里要格外克制。个人仓库随便折腾，公共仓库强推之前先确认没有别人在基于这个分支工作。

还有一个高频变体：error: failed to push some refs后面跟着Updates were rejected because the remote contains work that you do not have locally。本质是同一个问题，处理方式一样。

4. 分支不是高手专属，是普通人的保命绳

很多人觉得分支是团队协作才用的东西，"我一个人写，直接在主分支上改就行"。这种用法在项目还小的时候没感觉，等代码量上去，一次改崩了想回退，才发现没有退路。

4.1 为什么建议你从第一天就用分支

分支的本质是"一条独立的提交线"。在分支上做的所有提交，主分支完全不受影响。这给你两个能力：试错和局部回退。

试错的场景：你想换一种实现方式，但不确定效果。开个分支去改，改完发现不行，git switch main回来，原来的分支删掉，主分支毫发无损。如果没有分支，你得手动把改动一行行改回去。

局部回退的场景：分支上的功能只做了一半，突然要紧急修一个线上问题。切回主分支处理，处理完再切回去继续，两条线互不干扰。

常用命令：

git switch -c feature/login-page # 新建并切换到分支 git switch main # 切回主分支 git branch # 看本地所有分支 git branch -a # 看远程分支 git branch -d 分支名 # 删除已合并的分支 git merge 分支名 # 把某分支合并进当前分支

老教程里用git checkout -b，新版本推荐git switch -c，语义更清楚，因为checkout这个命令同时承担了切换分支和恢复文件两个职责，容易误用。

分支命名上，我习惯用feat/xxx、fix/xxx这样的前缀，一眼能看出这条分支在干什么。分支名不要用大写和空格，跟仓库名的规则一样。

4.2 冲突到底长什么样：一次手动解冲突的全过程

冲突（conflict）这个词吓退过不少人。它的实质很简单：同一个文件的同一处位置，两边都改了，Git 不知道听谁的。

造一个例子。主分支上某行是const timeout = 3000，你在分支上改成5000，同时主分支也被别人改成了8000。你在分支上执行git merge main，冲突就来了：

Auto-merging config.js CONFLICT (content): Merge conflict in config.js Automatic merge failed; fix conflicts and then commit the result.

打开 config.js，会看到：

<<<<<<< HEAD const timeout = 5000; ======= const timeout = 8000; >>>>>>> main

三个标记的含义：<<<<<<< HEAD到=======之间是当前分支的内容，=======到>>>>>>> main之间是被合并进来的内容。

解决步骤：

1. 手动编辑这个文件，删掉三个标记行，把最终想要的内容留下来。可能选一边，也可能两边都不要，写出第三个值const timeout = 6000。
2. 保存，git add config.js告诉 Git "这个文件我处理好了"。
3. git commit完成合并（不需要-m，Git 会给出默认信息）。

几个实战经验：

冲突时不要慌着删文件重来。绝大多数冲突都是几行代码，看着标记改就行。真要放弃，git merge --abort可以回到合并前的状态。

冲突标记一定要删干净。我见过最经典的事故是标记行被留在了代码里，然后一路提交上线。所以解完冲突后，全局搜一遍<<<<<<<，确认零命中。

能用工具就别硬刚。VS Code 内置了冲突解决界面，直接在编辑器里点"采用当前/采用传入/两者都保留"就行，比手动删标记快得多。

冲突其实是个好信号。它说明有人和你改了同一处，早点发现比晚点发现强。真正危险的是"没冲突但逻辑互相覆盖"，那种 Git 帮不了你。

4.3 合并、变基、还是直接覆盖：几种收尾方式的选择

分支开发完成，收回主干的路径有几种，选错了会留下很难看的历史。

merge：git switch main && git merge feature/xxx。保留分支的完整历史，会产生一个合并提交。好处是真实、可追溯，坏处是分支多时历史图形状复杂。

squash merge：把分支上的多个提交压成一个，再合并。适合"分支上有一堆wip、fix typo之类的碎提交，不想污染主干"的情况。在网页端提 PR 时可以直接选 Squash and merge。

rebase：把你的提交"重放"到目标分支的最新提交之上。历史是一条直线，非常干净。但不要在别人已经基于你的分支工作之后再 rebase，因为提交哈希会变，别人拉下来会一团乱。

我的习惯是：个人分支用 squash 合并，保持主干干净；涉及多人协作的大功能用 merge，保留完整脉络；rebase 只在自己独占的分支上、推之前用来整理提交。

5. Issue 和 Pull Request：把你的改动讲给别人听

这两个功能是 GitHub 区别于"网盘"的核心。哪怕你不参与开源，自己一个人用，它们也能帮你管住任务和改动。

5.1 Issue 不是留言板，是任务卡片

Issue 的字面意思是"议题"，实际用法更接近"待办事项"。一个好的 Issue 应该包含：现象、期望、复现步骤、环境信息。

举个对比例子。差的写法："登录有问题，麻烦看下。" 好的写法：

标题：登录页在 Safari 下点击无响应 现象：Safari 17 打开登录页，点击"提交"按钮无任何反应，控制台无报错。 期望：正常提交并跳转。 复现：1. Safari 打开 /login 2. 填入任意账号密码 3. 点击提交 环境：Safari 17.2 / macOS 14.2 补充：Chrome 下正常，怀疑是某个 API 兼容性问题。

后者拿到手就能开工，前者得来回问三轮。写 Issue 的功夫，本质上是在替未来的自己省沟通成本。

Issue 还能用标签（Label）分类，比如bug、enhancement、question；用里程碑（Milestone）归拢一批；用@提醒相关人。个人项目里，我一般只用todo和bug两个标签，够用。

一个实用技巧：提交信息里写fix #12，推送后 GitHub 会自动关闭第 12 号 Issue，并建立关联。这个小机制能把"改代码"和"任务追踪"串起来。

5.2 提 PR 之前，先过一遍这张自查表

Pull Request（PR）是"请求把我的分支合并进目标分支"。它的价值不在于提交动作本身，而在于给改动配一份说明，让看的人能在五分钟内理解你做了什么。

提之前先自查：

PR 描述我一般按三段写：背景（为什么要改）、改动（改了什么）、验证（怎么确认没问题）。如果是修 UI，附一张对比截图，比写一百字都有用。

还有一个细节：PR 要小。一次改三千行的 PR，评审的人基本只会点个"看起来没问题"就过了，等于没审。拆成几个小 PR，每个改一两百行，问题更容易被发现。

5.3 收到别人的 PR，你该看哪几眼

如果你维护一个仓库，收到 PR 后别急着点 Merge。按这个顺序看：

先看改了哪些文件。如果 PR 说的是"修复按钮样式"，结果改了十几个配置文件，那就要问一句了。

再看核心 diff。重点看边界条件：空值、异常、超长输入、并发。这些是 bug 的高发区。

然后本地跑一遍。网页上看 diff 看不出运行时问题。拉分支下来跑测试，是性价比最高的一步。

最后看提交信息与描述是否对得上。对不上说明作者自己也没理清。

合并方式上，前面说的 squash 适合碎提交多的 PR，merge 适合需要保留脉络的大改动。合并之后记得删掉远程的源分支，否则分支列表会越来越长。

6. README、.gitignore、LICENSE：三个小文件决定别人对你的第一印象

这三个文件加起来不到一百行，但对仓库的"观感"影响极大。很多人仓库里的代码写得不错，就是没人 star，问题往往出在这儿。

6.1 README 到底该写什么，不该写什么

README 是仓库首页自动渲染的内容。一个能让人留下来的 README，通常包含这几块：

一句话说明这是什么。放在最顶部，直接讲清楚用途，不要写"这是一个基于 XX 技术的 XX 系统"这种空话，要写"用来把 Excel 里的地址批量转成经纬度"这种具体的。

一张截图或一段演示。人对图像的反应远快于文字。有界面就放界面，没界面就放一段终端输出的示例。

怎么跑起来。这部分要能直接复制粘贴，把依赖、命令、常见前置条件都写上。新手最常犯的错是省略了环境要求，比如"需要 Node 18 以上"，结果别人用 16 跑不起来。

目录结构说明。项目大一点就该有，帮人快速定位。

已知限制。坦白写出"目前只支持 Windows"这种，比让人踩坑强。

不该写的：大段的自我介绍、跟项目无关的感慨、过长的发展规划。README 是说明书，不是日记。

再加一个小细节：在 README 顶部加几个徽章（构建状态、许可证、版本号），虽然只是装饰，但会让人觉得这个项目"是活的"。

6.2 .gitignore 写错，等于把垃圾永久钉在仓库里

.gitignore的作用是告诉 Git"这些文件不要跟踪"。它在仓库根目录，一行一条规则。

最典型的漏配后果是：把node_modules提交上去，仓库瞬间多几万个文件，clone 一次要等半天。更麻烦的是，一旦某个文件已经被提交过，之后再加进 .gitignore 是不生效的，因为 Git 已经在跟踪它了。

补救方法：

git rm -r --cached node_modules git commit -m "chore: 移除误提交的依赖目录"

--cached表示只从 Git 索引里删，本地文件保留。这一步做完再提交，文件才会真正从跟踪列表里消失。

常见的忽略项，按项目类型分：

# 通用 .DS_Store Thumbs.db *.log # Node node_modules/ dist/ .env # Python __pycache__/ *.pyc venv/ .venv/ # IDE .idea/ .vscode/

注意：.env一定要忽略。这类文件里通常放数据库密码、接口密钥，提交上去就等于公开了。如果不小心提交了，光删文件没用，历史记录里还在，得用专门的历史清理手段，而且密钥必须立刻作废重发，因为已经泄露了。

6.3 提交前的最后一道门：密钥与配置文件的处理

在按下git commit之前，我固定会做两件事：git status看一遍改了哪些文件，git diff --staged扫一眼具体内容。这两步大概花十秒，能挡掉绝大多数事故。

对于配置类内容，正确的做法是"模板 + 忽略"：仓库里放一个.env.example，写清楚需要哪些字段但不填真实值；真实的.env加进.gitignore。新人 clone 下来复制一份改改就能跑。

还有一种情况是本地路径。有些配置文件里会写死绝对路径，比如D:/projects/xxx，提交上去别人根本用不了。这类文件要么忽略，要么改成相对路径。

如果仓库里已经混进了不该有的东西，别急着强推覆盖。先确认有没有别人拉过这个仓库，如果有，强推会打乱他们的本地状态。稳妥的做法是正常提交一次删除，然后在说明里讲清楚。

7. 新手高频报错的定位思路与恢复手段

命令记不住没关系，出错能救回来才是真本事。这一节挑几个最高频的问题，重点讲排查思路。

7.1 认证失败、权限被拒的三种典型面孔

面孔一：Permission denied (publickey)。SSH 密钥没配好。排查：ssh -T git@github.com看具体报错；确认~/.ssh/下有私钥；确认公钥已经贴到网页上；确认ssh-agent里加载了密钥（ssh-add -l查看）。如果之前配过别的密钥，可能需要在~/.ssh/config里指定用哪个。

面孔二：remote: Support for password authentication was removed。说明你在用账号密码推 HTTPS，现在不支持了。改用个人访问令牌，或者换 SSH。

面孔三：403 Forbidden。通常是令牌权限不够。生成令牌时要勾选repo相关权限，否则能读不能写。

排查顺序上，先确认远程地址对不对：

git remote -v

我见过有人把别人的仓库地址配成了自己的 origin，然后一直推不上去还以为是权限问题。

7.2 改坏了、删错了：reflog 与 restore 的用法

场景一：改了一个文件，还没提交，想还原。

git restore 文件名

工作区的修改直接丢弃，不可恢复，执行前想清楚。

场景二：已经git add了，想撤回暂存。

git restore --staged 文件名

文件内容不变，只是从暂存区拿回来。

场景三：提交了但想改最后一次提交。

git commit --amend -m "新的说明"

注意，如果这次提交已经推送到远程，amend 之后需要强推，团队协作时慎用。

场景四：git reset --hard之后发现改错了，想找回来。

这是git reflog的舞台。它记录了 HEAD 的每一次移动：

git reflog # 找到出错前那一条的哈希，比如 a1b2c3d git reset --hard a1b2c3d

reflog默认保留 90 天，只要提交过的东西基本都能捞回来。这个命令应该早点知道，它是新手最容易踩的"不可逆操作"的保险绳。

场景五：整个分支误删了。

git reflog git switch -c 分支名 哈希值

只要分支上有过提交，就能重建。

7.3 一个可以照着走的排错顺序

遇到问题卡住时，按这个顺序来，八成能自己解决：

1. 读报错原文。别只看最后一行，往上翻几行，真正的信息往往在中间。看不懂的英文单词逐个查。
2. git status。它会告诉你当前处于什么状态：有没有未完成的合并、有没有冲突文件、在哪个分支。
3. git log --oneline --graph -10。看清最近十条提交的走向，确认本地和远程的关系。
4. git remote -v。确认地址没配错。
5. 判断是"本地问题"还是"网络/权限问题"。ssh -T或ping一下能快速区分。
6. 去搜报错。搜的时候带上关键短语和错误码，别搜整段中文翻译。
7. 最后才考虑重来。删掉目录重新 clone 确实能解决大部分问题，但那样你就永远学不会了。

我在实际操作中的体会是：新手阶段最值钱的不是记住多少命令，而是建立起"当前处于哪个状态"的感知。git status和git log这两个命令看起来朴素，但它们能把你从"玄学"拉回"事实"。很多人一遇到问题就慌，是因为不知道自己在哪；一旦能看清状态，问题就变成了一道有步骤的题，慢慢解总能解出来。

最后再分享一个小技巧：把你常用的命令写进一个notes.md，跟着自己的项目走。别人的速查表再全，也不如自己踩过坑之后记下的那几条管用。我用到现在的那份笔记里，一半以上都是当初报错之后抄下来的命令加一句"为什么"，比任何教程都贴心。