关于 GitHub 的 100 个问题

写在前面

这是一套「100 个问题」主题文档：用问题把一个主题拆开，再一个问题一个问题地读透。

GitHub 不只是程序员的代码仓库。它可以存作品、做作品集、托管静态站点、参与开源、管理写作，甚至用 Actions 自动跑任务。这份文档按 6 个阶段展开：先判断要不要学，再零基础第一天不碰命令行也能用起来，然后避开最痛的坑、学会搜项目和跑项目、把自己的东西存好秀出来，最后判断该学到什么程度。

快速回答

• GitHub 值得学，但先把它当「可展示、可协作、可长期保存的工作台」，不是一堆 Git 命令。
• 第一天用网页版或 GitHub Desktop，先完成一次真实提交，再学命令行。
• 先读 README，再决定要不要跑；看不懂就丢给 AI 解释。
• 密钥、密码、身份证号绝不能提交；一旦提交，先撤销再轮换。
• 想清楚你要的是存储、展示、协作还是自动化，不同目标对应不同深度。

本文整理自 GitHub 主题文档与公开资料，并结合站内编辑做了结构化整理与补全。

本册为整理版：部分原始资料存在 OCR 截断，正文以可执行的问题清单和简明回答为主。

第一章 · 我到底要不要学？现在还来得及吗？

你大概听过一种说法，GitHub 是程序员的事，跟普通人没关系。可真要去注册一个账号，又拿不准这东西到底能给自己带来什么。这一章不跟你讲命令、不跟你讲原理，先把一件事说清楚：GitHub 从一开始面向的就不止写代码的人，它更像一个四合一的地方，理解了这个，后面的所有问题才有了落点。

1. AI 这么猛，不会代码学 GitHub 还有意义吗？

你大概听过一种说法，AI 都能帮人写代码了，那还学 GitHub 干啥。这话只说对了一半。AI 帮你把代码写出来，可代码写完了存在哪、怎么和别人一起改、怎么让人看到你做过什么、怎么进到开源社区里去，这些事 AI 替不了你。GitHub 面向的从来不止写代码的人，它更像一个四合一的地方：代码保险箱、多人协作台、全球开源社区、还有你的技术名片。哪怕你一行代码不写，只是把文档、笔记、练手的小项目传上去，它也在帮你做备份和沉淀。AI 把生成的门槛降下来了，反而让把成果存好、秀出去、和别人接上这件事变得更值钱。说到底，学 GitHub 不是学一门语言，是给自己备一个随手能用的成果存放和展示台。除了

这四件大事，它里面还藏着 Issue 当待办、Projects 当看板、Pages 变网站、Actions 自动跑任务这些顺手功能，而且开源不等于免费乱用，每个项目都带着许可证，商用前得看清能不能用、怎么署名。

2. 都说 GitHub 是程序员的事，普通人碰它到底图什么？

图的就是那四件事，而且每一件都和是不是程序员没关系。第一是备份，代码推上去等于多了一份云端存档，它像保险箱加时间机器，既能防丢，又能回到任意历史版本。第二是协作，多个人改同一份东西，各改各的分支，系统聪明地把改动合并，不会互相覆盖。第三是开源，全球最大的开源社区就在上面，别人写好的轮子你能直接拿来用。第四是名片，一个活跃整洁的主页比又头说熟悉某项技能有说服力得多。普通人碰它，图的不是写代码，是给自己找一个能存、能协作、能白嫖好东西、还能展示的地方。这里要提醒一句，开源不等于免费乱用，每个项目都带着许可证，商用前看清能不能用、怎么署名，这事儿和水平高低无关，谁用谁都得守。把代码推上去，电脑进水硬盘坏了，换个电脑重新下载就能满血复活，这是备份最实在的好处。

3. 网上说 GitHub 是第二张简历，真有人靠主页拿到 offer 吗？

不少公司招人的时候，第一件事就是翻应聘者的 GitHub 主页，招聘方也常看一个主页活不活跃、整不整洁。它直接展示三样东西：你写过哪些真实项目、你的代码风格怎么样、你有没有持续在学、有没有参与过开源。哪怕是学校作业、练手的小项目，传上去积少成多，主页就是你的活简历。现在连设计师都用 GitHub Pages 搭个人网站和作品集，把主页做成一张直观的名片，这已经不是程序员的专利。而且主页里还藏着 Issue、Projects、Pages 这些功能，它不只是一堆代码，也是你管理项目和展示成果的地方。所以主页能不能帮你拿到 offer，关键看你有没有认真往上放东西，空着的主页当然谁也帮不了你。招聘方翻主页，看的是实打实的项目和持续度，不是一页能编出来的自述，这一点恰恰是你的机会。

4. 我现在才起步，会不会早被别人甩开太远、追不上了？

GitHub 的价值靠的是积累，但它从来不是一场比谁起步早的赛跑。有个被反复验证过的心法：持续用才是王道，教程看十遍不如自己传十个仓库。也就是说，

真正拉开差距的，看你有没有真的把东西用起来，不看你哪天注册的账号。越早开始，复利确实越大，可复利的前提是动起来，光等着没用。你现在担心追不上，不如今天就把第一个仓库传上去，哪怕只是放一份读书笔记。传十个仓库的人，永远比看了十遍教程没动手的人走得更远，这件事上没有谁被谁甩开，只有谁先开始持续用。再说，GitHub 的进阶功能像打标签、发版本、Pages、Actions、参与开源，都是按目标挑着用的，不用一又气学完，也就不存在落后多少这一说，你从哪个功能切进去都不晚。

5. 公司没要求、学校没教，我到底为什么该花这个时间？

因为这件事的收益是长期的，而且不挑场景。把它当成你的编程作品集加云备份加学习社区，越早开始用，复利越大。公司没要求，是学校没教，不代表它对你没用，恰恰可能是身边大多数人还没意识到的那块短板。你写的东西、改的东西、参与讨论的东西，都会留在上面变成你的痕迹，下次换电脑、换工作、想证明自己做过什么，打开就能用。它还是一个学习社区，你能看到别人怎么写、怎么协作、怎么解决问题，这种氛围本身就在推着你进步。花的时间不是上课那种消耗，是给自己搭一个会随时间增值的架子。等哪天你真需要用的时候，已经有一堆现

成的内容在那儿了，这才是它值得提前花时间的理由。它不像社交账号那样容易荒废，仓库一旦建了就一直在，是越放越值钱的东西。

6. 看别人主页很厉害，我这种菜鸟进去会不会一眼露怯？

露怯这件事，在 GitHub 上其实没你想得那么严重，因为它本来就是给所有水平的人用的。GitHub 的设计逻辑很直白，哪怕是学校作业、练手的小项目，也鼓励你传上去，积少成多主页就是你的活简历。没有人要求你一进去就得发什么厉害的东西，从传一份课程作业、一篇笔记开始，主页一点点丰满起来，这才是正常路径。现在不少设计师、非技术背景的人也在上面用 Pages 搭作品集和简历，他们同样是从零开始。就连把仓库变成网站的 Pages 功能，新手也能用，搭个简单主页并不比写篇博客难。你看到那些很厉害的主页，背后也是一个个小项目堆出来的，不是天生就那样。先传第一个，比坐在外面觉得自己菜要实在得多。主页不怕简单，怕的是一直空着，传一个是一个，比纠结自己够不够格有用。

7. 听说 GitHub 越用越上头，什么人最容易收藏了就吃灰？

最容易吃灰的，是把 GitHub 当成又一个收藏夹的人。有个很实在的道理：教程看十遍，不如自己传十个仓库。只收藏不动作，账号永远是个空架子，时间一长自然就忘了。反过来，那些真的用起来的人，往往是先想清楚自己要它干什么，比如怕电脑崩所以拿来备份、想和别人协作所以拿来管项目、想秀作品所以拿来搭主页。有了具体目标，才不会收藏完就丢。你可以把 Issue 当待办清单、把 Projects 当看板，这些顺手功能接进日常，账号就活了。所以你如果怕吃灰，别一上来收藏一堆教程，先给自己找一个最小的使用理由，传第一个仓库，让它在你的真实生活里派上用场，它就不会躺在那儿吃灰了。传十个仓库的人，主页自然就活了，吃灰的永远是那些只注册不动作的人。

8. 不学 GitHub、只靠 AI 工具干活，将来会缺哪块关键能力？

只靠 AI 工具，你手里多了一个会写代码的帮手，但缺的是把成果安顿好的那一整块能力。AI 帮你生成，GitHub 帮你把生成的东西存成备份、变成协作、接进开源社区、沉淀成一张别人看得见的名片，这四件事 AI 工具本身不给。你写的 Prompt 再好，代码如果不落地到一个能版本管理、能多人一起改、能展示给招聘方看的地方，它就只是一次性的对话记录。开源社区里别人写好的轮子你能直接拿来用，这种现成资源的入口，也只有进了 GitHub 才真正打开。将来真正值

钱的，往往是那个持续积累的主页和参与过的项目，而不是某天用 AI 生成过什么。所以学 GitHub，补的正是只靠 AI 干活时最容易被忽略的存放、协作和展示这一环。AI 给的是一次性的产出，GitHub 给的是能反复用的积累，这两样合起来才完整，缺了后头那块，前面生成得再快也留不住。

9. 学 GitHub 是不是等于先把一堆 Git 命令背熟才行？

完全不是。很多人被劝退，就是卡在以为要先背熟一堆命令才能开始。其实 GitHub 的本质是备份、协作、开源、名片这四件事，命令只是实现手段里的一种，而且是最不需要急着背的那一种。你现在完全可以用网页点一点就把东西传上去，也可以用 GitHub 桌面版这种图形工具，不碰命令行也能完成大部分操作。命令是给那些想更精细控制的人准备的，不是入门门票。真正要背的没几个，常用的那几个等用到了再学一遍自然就记住了，一点都不晚。先把这四件事理解透，知道 GitHub 能帮你做什么，比死记硬背命令有用得多。网页上传文件、点绿色按钮就能提交，这条路径从头到尾不碰命令行。真要学命令也是那几个常用的，git add、git commit、git push 之类，用到再查就行，入门阶段完全绕得开。

10. 免费资源那么多，GitHub 和 B 站、慕课到底差在哪？

B 站和慕课帮你学，GitHub 帮你把学的东西落地，这是根本区别。看教程是输入，把代码传上去、把项目跑起来、把作品秀出去，是输出和沉淀，这两件事得在不同的地方完成。GitHub 那个四合一的价值，慕课给不了：慕课不会帮你做云端备份，不会让你和多个人实时协作改同一份项目，不会让你的成果变成一个招聘方随时能翻的主页，也不会把你接进全球开源社区。你还能在 GitHub 上给喜欢的项目修 bug、提建议，这种实打实的参与慕课也给不了。你可以先在慕课上学，再把练手的项目传到 GitHub 上，让它变成你自己的东西。把两者配合起来用，才是一个完整的从学到秀的闭环，光看不存，学过的很容易就散了。慕课教你怎么做，GitHub 让你做出来的东西被人看见、被人一起改，这是输出端的事，前者单独给不了。

11. 想做个作品集给面试官看，GitHub 比做 PPT 简历强在哪？

强在它是活的，而且骗不了人。PPT 简历写的是你声称自己会什么，GitHub 主页直接展示你写过哪些真实项目、代码风格怎么样、有没有参与过开源、是不是

还在持续学。招聘方翻主页的时候，看到的是实打实的东西，不是一页精心排版的自述。一个活跃整洁的主页，比简历上写熟悉某项技能有说服力得多，这一点招聘方普遍认。现在连设计师都用 GitHub Pages 把主页做成可访问的网站和作品集，点开就能看，比发一份 PDF 直观。Pages 本身是把仓库变成静态网站，适合放简历、项目说明和文档，纯静态不用跑后端。所以如果你要证明自己真做过东西，主页比 PPT 更难造假也更打动人，它替你说话，不用你自己吹。PPT 发出去就静态了，主页你还在持续更新，它跟着你一起长，招聘方下次翻还能看到新东西。

12. 身边人都说赶紧学我又怕白费劲，怎么判断自己该不该入坑？

最简单的办法，拿那四件事对照自己的真实需求，命中任何一项就值得入。怕电脑崩、想给重要文件多一份云端备份，这是第一项。经常要和别人一起改东西、受够了文件传来传去，这是第二项。想白嫖别人写好的工具框架、不想重复造轮子，这是第三项。想有个能展示作品、让招聘方或客户看到你做过什么的地方，这是第四项。只要有一条戳中你，GitHub 就不是白费劲，拿备份这一条来说，电脑真坏了能满血复活，光这一项就值回票价。反过来，如果你现在完全没有这些需求，也不打算做任何项目，那确实可以先放一放。判断该不该入坑，看的不

是别人催不催，是你自己有没有用得上的场景。很多人是等工作要用、面试要展示才想起来建，那时候再补就赶了，提前建永远不亏。

13. GitHub 上有免费 AI 模型能玩，跟我有什么关系？

这说的是 GitHub Models，它是 GitHub 里集成的一批现成 AI 模型，相当于一个 AI 模型市场。里面有 GPT-4o、Llama 3.1、Phi-3、Mistral 这些来自不同公司的模型，在试想法、做原型的阶段都能免费试。两种玩法最实在，一个是网页里的 Playground，打开浏览器就能问问题、调参数、把两个模型放一起比输出，不用下载模型也不用付钱。另一个是 API 和 SDK，想接进项目就用你 GitHub 账号的 token 去调，不用单独买 API key。免费当然有限制，每分钟每天有请求次数上限，小模型宽松些、GPT-4o 这类紧一点，真要上生产环境官方建议迁到付费的端点，但代码基本不用改。对不写代码的人，最划算的就是那个网页 Playground，不用装环境不用掏钱，进去就能和前沿模型对话。

14. 非技术人学 GitHub，最后能落到哪些具体好处？

落到手上是三件很实在的事。第一是备份和存放，你的文档、笔记、资料不用只躺在本地硬盘，推上去就多了一份云端存档，既能防丢，又能回到任意历史版本。

第二是展示，用 GitHub Pages 搭个个人网站或作品集，设计师、运营、写作者都能把自己的东西做成一张直观的在线名片，点开就能看。第三是蹭上 AI 的快车，GitHub Models 那个网页 Playground 让不写代码的人也能免费和前沿模型对话、试想法，不用装环境。这三件事加在一起，等于你用很低的门槛，给自己备了一个能存、能秀、还能玩 AI 的地方。它不会让你瞬间变成工程师，但能让你在 AI 时代多一个普通人也能用的抓手。Pages 搭网站纯静态不用跑后端，Models 玩模型不用装环境，都是低门槛的入口，普通人也能在 GitHub 上找到自己的位置。

第二章 · 零基础第一天，怎么不碰命令行也能用起来？

第一次点开 GitHub，满屏英文按钮像进了异国超市，货架都认识半个词，就是不知道从哪下手。这一章不教你怎么背命令，只告诉你第一天该碰哪几个地方、哪些按钮点了没事、哪些可以完全跳过。很多人卡住不是因为难，是因为一上来就想把 Git 搞懂，其实你前三天根本用不到命令行。先把网页能做的事做顺，再决定要不要往下走。

15. 打开一个 GitHub 仓库全是英文按钮，第一天该先看哪几个？

进到一个仓库，别被那一排英文吓住。先盯页面顶部那行标签就够了：Code 是代码和下载入口，Issues 是别人提的问题和建议，Pull requests 是别人想合并进来的改动，剩下的 Actions、Projects、Wiki 头几天基本用不到，先当没看见。往下看，右边栏 About 里那几个数字最值得扫一眼：Stars 是大家点过喜欢的数量，Forks 是被复印出去的份数，Languages 告诉你这项目主要用什么语言写的。

第一次看一个仓库，顺序是先看简介和 README 明白它是干嘛的，再看 Issues 了解别人踩过什么坑，最后才看代码。页面上每个词都能点，点错了也能退回来，放心逛。真正第一天要记的只有三样东西的位置：右上角的 Star、Watch、Fork，以及那个绿色 Code 按钮在哪儿。其他全当背景，用到再说。

16. 不装 Git、不敲命令，光用网页怎么把东西存上去？

很多人以为用 GitHub 第一步就得装 Git、敲命令，其实完全不用。你注册完登录，点右上角加号新建一个仓库，起个名字、写一句说明，仓库就建好了。建好之后，仓库页面里有个上传入口，你可以直接把电脑里的文件拖进去，或者点按钮选文件，填一句提交说明，点确认，东西就存上去了。整个过程鼠标点完，一个命令都不用敲。网页上改文件也同样简单：点开任意一个文件，右上角有个铅笔图标，点进去就能改，改完填说明保存，这本身就是一次提交。对第一天来说，能拖能改就够用了。等你以后真要天天传代码，再考虑装 Git 或者用桌面版也不迟。先让东西上得了架，比纠结工具顺手重要得多。命令行是后面的事，不是门槛。即使之后你想学

命令行，第一天用网页建好的仓库和传上去的文件也都能接着用，不会因为换了工具就作废，所以放心从最简单的开始。

17. 仓库页面那个绿色 Code 按钮点开是干嘛的，为什么新手最容易懵？

那个绿色 Code 按钮，是下载和克隆这个仓库的入口。点开它会弹出一个框，里面有仓库地址、一个 Download ZIP 选项，还有用桌面版打开的按钮。它不神秘，就是让你把项目弄到手。新手最容易懵，是因为选项太多、名字又陌生。最常见的一个坑：想直接下压缩包，手一滑点成了 Open with GitHub Desktop，结果电脑开始装软件，莫名其妙。其实你只要选 Download ZIP，就能直接下载一个压缩包，解压就能看。另一个坑是 Clone 那一串网址，新手以为要抄下来敲命令，其实网页下载压根不需要它。记住一句话：只想看、想存，点 Download ZIP 就行；想用命令行或者桌面版同步，才去碰那串地址。第一天你大概率只需要 Download ZIP 这一个动作。

18. Star、Watch、Fork 这三个按钮到底差在哪，乱点会出事吗？

这三个按钮天天被混着说，其实目的完全不同。Star 等于点赞收藏，点一下就把项目收进你的喜欢列表，以后在 Your stars 里能找回，顺手给作者加了点人气。Watch 是订阅动态，项目一有更新、新 Issue、新 PR，你的通知里就会收到提醒。Fork 是复印一份到自己账号下，你可以随便改、改完能提 PR 还回去。乱点会不会出事？基本不会。Star 和 Watch 只是接收信息，不碰代码，点错了取消就行。Fork 会在你账号下生成一个副本，但那只是副本，不会影响原项目，也不会自动同步原作者的更新，放着不动也没事。一句话：想收藏点 Star，想跟进更新点 Watch，想改代码或提贡献再点 Fork。前两个随便点，Fork 想清楚再点就行，都不会把天弄塌。

19. 别人说先 Fork 再改，Fork 到底是复制还是关联？

Fork 听起来像复制，但准确说是在 GitHub 上给自己复印了一份别人的仓库。点完 Fork，你的账号下会出现一个同名仓库，这就是你的副本，原作者的那份叫上游。它和关联的区别在于：副本是实打实存在你账号里的独立仓库，你能在上面随便改，改坏了也不影响原作者。但它不是自动关联的，原作者更新了，你的副本不会自动跟着变，得你手动去同步。

所以 Fork 既是复制也是起点：复制给你一份能改的家底，起点是说你想给开源项目做贡献，标准做法就是先 Fork，在自己的副本上改，改完提 PR 还回去。提一句安心的话：Fork 不是抄袭，是开源协作的标准动作，只要保留原作者的版权声明就没问题。MIT 这类许可证本来就允许你 Fork 后修改。

20. 我想把别人的项目弄到自己账号下，克隆和 Fork 该选哪个？

先说清楚两个动作分别干嘛。Clone 是把仓库下载到你本地电脑，方便在本地看代码、改文件。Fork 是把仓库复印一份到你自己的 GitHub 账号下，存在云端。如果你只是想看看代码、跑一跑、自己研究，clone 就够了，连账号都不用动。如果你不光想看，还想改，还想把改动提回原项目，那就得 Fork，因为 clone 下来的是原作者的仓库，你没权限直接往里推。常见组合是 Fork 加 clone：先 Fork 到账号下，再 clone 你自己的那份到本地，改完推回你的副本，最后提 PR。这样你既有云端的副本，也有本地的编辑环境。头几天如果只是浏览和收藏，clone 或者直接 Download ZIP 都行。等到你真想贡献代码，再走 Fork 这条路。按需选，别一上来就全做。

21. 不装软件，网页里按一下小数点就能在线改代码，怎么借它上手？

这是个很多人不知道的偷懒神器。你在一个 GitHub 仓库页面，直接按键盘上的小数点，浏览器会跳到一个叫 github.dev 的网页编辑器，界面跟写代码常用的工具几乎一样，但什么都不用装。进去之后，你能像在本地编辑器那样浏览文件、改内容、存改动。改完填一句提交说明，就能把改动直接提交回去，全程在浏览器里完成，不用装 Git，也不用在本地配环境。它和网页里点铅笔改单个文件比，强在能同时看多个文件、有目录树、有搜索，更像正经干活的环境。适合你临时想改点东西、又不想为这一下大动干戈装一套工具的时候。记住这个键：在仓库页按小数点。第一次用会觉得捡到宝，尤其是你只想快速改个文档或者试一小段代码的时候。它甚至能直接打开别人仓库里的文件来读，比在网页里一层层点进目录方便。你不需要把它当成正式开发环境，就当临时工作台，用完关掉就行。

22. 配置 Git 用户名邮箱这一步能不能跳过，跳过会怎样？

不配第一次提交就会被拦下来，所以这一步躲不掉。Git 每次提交都会在你的改动上盖一个作者章，记录是谁、用的什么邮箱。这个章靠 user.name 和 user.email 来生成，没配就不知道写谁，提交直接报错。邮箱建议你用注册 GitHub 的那个，这样提交记录才能和你的账号对应上，主页绿格子和贡献统计才认得你。填错了也别慌，用同样的命令重设一次即可，以前记在错账号下的提交不会自动改，但以后的是对的。如果你用桌面版或者网页上传，很多情况下工具会帮你填好，不必自己敲命令。只有走命令行时才需要手动配。所以结论：命令行路线躲不过这步，但它就两条命令，配一次管很久。把它当成进门刷一下卡，麻烦三十秒，后面省一堆对不上的麻烦。可复制模板（直接复制使用）：# 配置提交时显示的名字和邮箱（换成你 GitHub 注册邮箱） git config --global user.name "你的英文名或昵称" git config --global user.email "you@example.com" # 一次性查看所有配置 git config --global --list

23. 配 SSH 密钥总报错权限被拒，到底是哪一步错了？

permission denied (publickey) 这句报错，八成出在公钥这一环，不是网络问题。SSH 是一对钥匙，私钥锁在你电脑上，公钥交给 GitHub，两边对上才放行。报错基本都和公钥交得对不对有关。最常见的错是复制公钥时没复制全：少了开头的 ssh-ed25519，或者结尾的邮箱被截断，贴到 GitHub 上自然对不上。正确做法是只复制带 .pub 后缀那个文件里的内容，从 ssh- 开头到邮箱结尾整段选中复制。另一种可能是你压根没把公钥加到 GitHub：得去 Settings 里的 SSH and GPG keys，点 New SSH key 把公钥贴进去保存。加完用 ssh -T git@github.com 测一下，看到 Hi 你的用户名就是通了。私钥千万别传出去也别上传仓库，一旦泄露立刻去删掉这把 key 重生成。报错先检查公钥复制整不整段，十次有八次是它。可复制模板（直接复制使用）：# 1. 检查电脑里是否已有密钥 ls -al ~/.ssh # 2. 生成新密钥（邮箱换成你的注册邮箱） ssh-keygen -t ed25519 -C "you@example.com"

代码提示： 3. 复制公钥（只复制带 .pub 的那把，私钥绝不外传） # macOS： pbcopy < ~/.ssh/id_ed25519.pub # Windows（Git Bash）： cat ~/.ssh/id_ed25519.pub | clip # 4. 测试连接（看到 Hi 用户名就是配通了） ssh -T git@github.com

24. 国内打开 GitHub 慢到转圈，有哪些不用翻墙也能加速的办法？

国内直连 GitHub 慢、图裂、clone 卡，根因是 DNS 污染加上境外节点拥塞，但这不意味着非得翻墙。有几招不用特殊工具就能用。最推荐的是改 hosts：用 GitHub520 维护的每日自动更新源，把那串域名和 IP 贴到系统 hosts 文件末尾，刷新一下 DNS 就能走通。这个方法零安装，用 SwitchHosts 还能设成每小时自动更新，一劳永逸。不想改文件的话，把网址里的 github.com 换成镜像站域名也能直接开，浏览器插件还能自动帮你跳转。clone 大仓库卡，可以把 https 换成 ssh 协议，抗干扰更强，前提是你配好了 SSH 密钥。要提醒一句：镜像站和代理站多半是只读的，别在那儿登录账号或上传私有代码，防 token 泄露。方法讲思路比记死域名稳，因为域名和 IP 会变。

25. 注册 GitHub 收不到验证邮件，除了干等还能怎么办？

注册时收不到验证邮件，先别急着重填账号。最常见的原因就几个：邮件落进了垃圾箱、注册时邮箱地址填错、邮箱服务商把 GitHub 的邮件拦了，或者你用了临时邮箱（这类地址 GitHub 明确不支持验证）。一步步排查：先翻垃圾邮件文件夹搜 GitHub；确认地址没错后，登录进 Settings 的 Emails 页面点 Resend verification email 重新发一封；还收不到就换一个可靠的个人邮箱，或联系 GitHub Support。提醒一句，验证链接 24 小时就过期，点开报错了就重新要一条。很多人卡在学校或企业邮箱，它们有时会屏蔽境外邮件，先用私人邮箱注册、之后在设置里换绑更稳。另外 GitHub 不支持用临时邮箱验证，别图省事用一次性地址，后面找回密码会很麻烦。

26. 第一次提交前，GitHub 桌面版和命令行该选哪个？

一句话：第一天用桌面版，别碰命令行。GitHub Desktop 是官方出的免费开源图形工具，提交、推送这些 Git 操作它都能在界面里点完，不用敲一行命令。对刚上手的人来说，它把那些吓人的命令藏在了按钮后面。

桌面版的好处是直观：你改了哪些文件、写了什么说明，界面上都看得清清楚楚，不容易因为敲错命令把事情搞乱。命令行效率高，但它要求你先理解一堆概念，第一天硬上容易劝退。等你觉得桌面版不够快、或者要批量处理、要写脚本的时候，再学命令行也不迟。两条路线最终干的活一样，只是操作方式不同。如果你连软件都不想装，网页版上传和按小数点进编辑器也能完成第一次提交。工具是手段，先让东西存上去，比选哪个工具重要。网上不少老教程一上来就让你敲命令，那是给要写代码的人准备的。你如果只是存文档、放资料、改改说明，完全不必跟着走那条路。

27. 仓库里那个 README 为什么人人让你先读，不读会怎样？

把仓库想成一间店面，README 就是门口的招牌加说明书。别人包括未来的你点进来，第一眼就读它来判断：这是个啥、怎么用、谁在维护。不读就上手，等于蒙着眼睛进店找东西。README 通常自动显示在仓库首页最上面，作者会把最重要的信息写在那：项目是干嘛的、怎么安装、怎么跑起来、有哪些注意事项。很多坑，作者其实早就在 README 里写明白了，你不读只能自己踩一遍。

不读的直接代价是走弯路：可能下错版本、漏了关键步骤、跑不起来还以为是项目有问题。花两分钟读 README，能省你两小时瞎折腾。写好 README 性价比也极高，因为它是仓库的门面。你自己的第一个仓库，也建议先放一份简单清楚的 README，别人一眼就能懂你在做什么。

28. 看到喜欢的项目想收藏，Star 和自建收藏夹哪个更靠谱？

先说结论：在 GitHub 内收藏，用 Star 比自建收藏夹更靠谱。Star 是平台原生的收藏机制，点一下项目就进你的 Your stars 列表，换设备、换浏览器都能看到，还自带按时间浏览。自建收藏夹如果是靠浏览器书签，换电脑就丢了，而且书签只存了网址，项目的更新、介绍你都看不到。Star 至少保留了你收藏时项目的基本信息和后续动态入口。还有一个 Star 顺手就给的好处：作者能看到 star 数涨，对你来说是零成本的鼓励。很多人在挑项目时也看 star 数当参考，你点的每一个 star 都在帮后来的读者。当然如果你收藏量大、想自己分类，可以 Star 之后再用列表或标签管理。但第一步，先养成顺手 Star 的习惯，比弄一套自己的收藏体系实在得多。

29. 分支听起来很高级，零基础第一天需要碰它吗？

第一天完全可以不碰分支，你先把东西存上去、看懂页面就够。分支确实是个重要概念，但它只是你以后要改东西、要协作时才用得上的工具，并非入门第一天就要碰的门槛。用个比方：分支像在主路旁边开一条小路，你在小路上随便改，不影响主路，改好了再把两条路合并。它的存在是为了多人同时改、或者你试错时不动主项目。第一天你一个人、只传自己的东西，主路直接用就行。等你要给别人的项目提改动、或者同时试两个想法时，再开分支。到时候记住一条就行：别直接在主分支上乱改，新功能或修 bug 都开新分支，试错了删掉分支，主项目毫发无伤。所以别被分支这个词吓住。它很轻量、创建几乎不占空间，但第一天你用不上，等真碰到要试错、要协作，它自然就登场了。真到了那天，你只要记住一条：动手改之前先开一条新分支，相当于先存档再试错，试错了删掉分支，主项目毫发无伤。

30. 我想把本地文件夹第一次传上去，最少敲哪几个词？

如果你走命令行，第一次把一个本地文件夹传上去，核心就是几个动作。先确保 Git 认得你：配好 user.name 和 user.email，这事配一次就行。然后进到你的文件夹，初始化一个仓库，把文件加进待提交区，写一句说明提交，再把本地仓库关联到你在 GitHub 上建好的那个空仓库，最后推送上去。这一串里真正要你敲的是 init、add、commit、remote add、push 这几个。如果你嫌多，最省事的替代是完全不用命令行：在 GitHub 网页新建仓库，回到本地把文件拖进上传区，或者点开文件用铅笔改完保存，鼠标点完就传上去了。所以最少敲几个词，取决于你选不选命令行。选命令行就那几个动作；不想敲，网页拖拽零命令也能完成第一次上传。第一天怎么省事怎么来。可复制模板（直接复制使用）：# 进入你的项目文件夹后，按顺序执行 git init git add. git commit -m "first commit" git branch -M main git remote add origin https://github.com/你的用户名/仓库名.git git push -u origin main

31. 界面左侧 Issues、Pull requests、Actions 都是给谁用的？

这三个标签页看着唬人，其实各管一摊，而且头几天你大多只是看，不是用。

Issues 是项目的留言板，别人在这儿提 bug、提功能建议、问问题。你是使用者时就来这儿看别人踩过什么坑、有没有现成答案；以后你真遇到问题也在这儿提。Pull requests 简称 PR，是别人想把自己改好的代码合并进项目时提交的请求。你看一个活跃项目就会理解，PR 越多说明有人在不断改进它。Actions 是自动化流水线，项目可以设定一些自动任务，比如有人提交代码就自动跑测试。普通用户第一天基本用不到，知道它存在就行。一句话：Issues 是提问题提建议的地方，PR 是别人求合并改动的地方，Actions 是自动跑任务的地方。你前期主要是逛 Issues 找答案，后两个等参与进去自然就懂了。

32. GitHub 界面能不能调中文，调了会不会反而看不懂英文教程？

能调，而且 GitHub 官方就支持简体中文界面，不用装汉化插件。登录后点右上角头像进 Settings，左侧找 Appearance，在 Language preferences 里选简体中文再保存，导航栏、按钮、菜单就都变中文了。不想登录也能看中文：把浏览器首选语言设成中文，或直接访问 github.com/zh-CN 强制加载。

但有个边界要清楚：这个设置只改 GitHub 自己的界面文字，仓库里的代码、README 还是原语言，不会跟着翻。顺带，看不懂某个功能时，去 docs.github.com/zh 这个官方中文文档站查，比硬翻英文界面轻松。部分新功能或高级设置的翻译可能略滞后，但核心功能的中文已覆盖得很全，日常使用完全够用。

33. 新手最容易把仓库和项目搞混，这俩在 GitHub 里是一回事吗？

在 GitHub 里，这两个词不是一回事，但确实容易混。仓库（Repository）是装代码和文件的地方，一个项目通常对应一个仓库。你看到的那个满屏文件的页面，就是一个仓库。它是实实在在的存储空间，你的代码、文档都躺在里面。项目（Projects）是另一个东西，它是 GitHub 里的一个看板工具，用来做任务管理，比如把一堆 Issue 和 PR 排成看板、跟踪进度。你点页面上的 Projects 标签才能进到它，普通浏览时基本用不到。所以区别是：仓库存东西，项目管任务。很多人说的我要建个 GitHub 项目，其实指的是建个仓库。头几天你只要搞清楚仓库就够了，Projects 看板是以后想系统管理任务再碰的进阶功能。

别被这两个词绕晕，记住仓库等于放代码的地方，先把它玩明白。

34. 用网页版直接改文件算不算提交，和本地提交有啥区别？

算，网页上改文件并保存，本身就是一次提交。你点开文件、按铅笔图标进入编辑、改完拉到底部点那个保存按钮，GitHub 就会记一笔提交，作者信息和说明都帮你填好框架，你补一句说明就行。和本地提交的区别在流程和工具。本地提交一般配合 Git 命令或桌面版，先把改动加进暂存区再提交，适合批量、频繁地改很多文件。网页改适合快速改一两个文件，比如改个错别字、补一句话，不用开任何软件。另一点区别：网页改每次只能针对单个文件，改完立刻生效在仓库里；本地可以攒一堆改动一次性提交，还能先检查一下再推。对第一天来说，网页改足够友好，零门槛。等你改得频繁了，自然会想用本地或桌面版提效率。两种提交记的都是同一套版本历史，没有高低之分，只是顺手不顺手。

第三章 · 为什么我一用就踩坑？那些最痛的坑怎么绕

踩坑这件事，几乎没人能跳过。你迟早会遇到 push 报错、冲突标记、或者手滑把不该传的东西传上去。这一章不是吓你，是给你一张查字典式的急救卡：遇到哪个坑，翻到对应那题，照着做就行。不用先背，遇到问题再来看。记住一条心法：大多数丢代码都能用 reflog 找回来，先别慌。

35. 推送时提示密码认证已移除，为什么按教程输密码就是不行？

你照着老教程输密码，Git 却报错说认证失败，不是你记错密码，是规则变了。GitHub 已经不再支持用账号密码登录命令行，这是平台统一改的，老教程没跟上。现在认证有两条路：要么用 SSH 密钥，把一对钥匙配好，以后上传自动放行；要么用 Personal Access Token，把它当密码用。Token 在 GitHub 设置里生成，长得一串乱码，比密码长得多。

很多人的卡点就在这：教程写的是密码，平台要的是 Token 或密钥。把认证方式换成这两种之一，报错立刻消失。如果你主要用网页或者桌面版，工具通常会帮你处理认证，连 Token 都不用自己管。只有走命令行推送时才必须面对这件事。提前配好 SSH，是省掉这个坑最干净的办法。

36. 手滑把密钥、密码甚至身份证号提交进仓库了，怎么彻底擦掉？

先把一句话记牢：密钥一旦传上去，默认就当已经泄露，最稳的做法是立刻去 GitHub 把那个密钥作废、重置，别指望只是删掉文件就安全。如果只是刚提交还没推送到 GitHub，事情简单：从版本库里删掉它、补一份 .gitignore 忽略掉，再提交一次覆盖就行。如果已经 push 出去了，光加 .gitignore 不够，因为文件还在历史记录里。得用专门的清理工具把那段历史抹掉，再去 GitHub 删掉对应文件、重置你的 Token 或密钥。切记别用 reset --hard 硬删，那会在历史里留痕，反而更麻烦。最省心的还是预防：项目一开始就配好 .gitignore，把 .env 这类装密码的文件挡在门外。密钥千万别早点传，传了就按作废处理。

37. .gitignore 没写对，导致一堆垃圾文件被传上去，怎么救？

.gitignore 是个黑名单，写进去的文件 Git 会自动无视。如果你发现 .DS_Store、node_modules 这类垃圾被传上去了，多半是规则写错了，或者文件在写忽略规则之前就已经被 Git 盯上了。先检查规则本身：每行一条，# 开头是注释，* 是通配符，末尾加斜杠只忽略文件夹。路径写多一个斜杠就可能不生效，用 git status 验证一下哪些还在被追踪。更常见的坑是：文件早就 commit 过，再写进 .gitignore 是无效的，因为 Git 已经在管它了。这时要先取消追踪，用命令把文件从版本库移除但保留本地，再提交一次，它才真正被忽略。最后记得把 .gitignore 自己提交进仓库，这样大家都能共享同一份忽略规则。项目一开始就把 .gitignore 配好，比事后补救轻松得多。可复制模板（直接复制使用）：# 注释以 # 开头 .DS_Store # macOS 系统文件 *.log # 所有日志文件 node_modules/ # 依赖目录（末尾 / 表示目录） .env # 密钥/密码文件（绝不提交！） dist/ # 打包输出目录

提示：建仓库时下拉选 .gitignore 模板，或搜 gitignore.io 在线生成

38. 提交信息乱写 fix update，后来自己都看不懂改了啥，有救吗？

提交说明就是每次存档时写的那句标题。新手常写 fix、update 这种词，过一周连自己都看不懂那天到底干了啥。先把好说明的标准记住三条：动词开头说清楚动作，比如添加登录页面、修复按钮错位；控制在一行内说清；如果团队协作，可以加个类型前缀，比如 feat 表示新功能、fix 表示修 bug、docs 表示改文档。已经写错的也别急，有办法补救。如果是最新那次提交写错了，或者漏加了个文件，可以用 amend 命令修改最近这一次，不用多挤出一条补救提交。但要注意，这个操作会改写历史，只改还没推送到 GitHub 的本地提交，已经推上去的就别动了。好的说明像日记标题，半年后回看一眼就知道那天干了啥。每次提交只围绕一个清晰的小目标，回滚和排查都轻松。可复制模板（直接复制使用）：# 好的提交信息：动词开头 + 说清改了什么 git commit -m "修复 README 中的拼写错误"

git commit -m "chore: 添加 .gitignore" git commit -m "feat: 新增登录按钮" # 常用前缀：fix 修 bug / feat 新功能 / docs 文档 / chore 杂务

39. 想反悔刚才的提交，reset、revert、checkout 到底该用哪个？

这三个都跟反悔有关，但危险程度差很多，别乱用。还没提交、只是改了文件想撤掉，用 restore 或者老写法 checkout，它们只动工作区，不碰历史，最安全，撤错了重编就行。已经提交了、想抹掉某次历史，有两个选择。revert 是新建一笔提交来反着改那次操作，原记录完整保留，像贴一张更正声明，团队项目首选，永远不会丢历史。reset 是另一种，尤其带 hard 参数会直接丢掉后面的改动，而且已推送到 GitHub 的提交别用 reset 乱改，会搞乱别人的代码。拿不准用哪个时，默认选 revert，它最不容易闯祸。只有本地、还没推送、纯个人草稿，才考虑 reset 那种危险操作。一句又诀：公开的历史用 revert，私下的草稿才 reset。

40. 合并分支冒出一堆冲突，那些 <<<<<<< 符号到底是什么鬼？

那些符号不是 bug，是 Git 在求你做决定。冲突发生在两个人改了同一行的同一处，Git 不知道听谁的，就把选择题摆在你面前。打开冲突文件，你会看到三样东西：<<<<<<< 到 ======= 之间是当前分支的内容，======= 到 >>>>>>> 之间是要合并进来的内容。你只要保留想要的那一版，把这三行标记全部删干净，文件就修好了。删完标记别忘两步：把文件加回暂存区，再提交一次，冲突才算解决完成。漏了这两步，合并不算结束。嫌手动麻烦也有偷懒法：用 VS Code 打开冲突文件，界面上直接有采用当前更改、采用传入更改的按钮；或者在 GitHub 网页的 PR 里点在线解决。遇到冲突先别慌，读标记、留对的、删标记、提交，四步搞定。

41. git add 到底该加单个文件还是整个目录，加错了怎么撤回？

git add 后面跟的，是你想让 Git 本次留意哪些文件。写法不同，挑选的范围就不同。

最精准的是加单个文件，只把那一个搬进暂存区，新手最推荐，慢一点但稳。想省事可以用加当前目录所有改动，但它会把你没注意的临时文件也一起加进去，加之前务必先 git status 看一眼，避免误加密码文件或依赖包。还有一种按块添加的模式，能只提交一个文件里改动的某几处，让每次提交更有主题。加错了完全能撤回，不丢内容：用 restore 把文件从暂存区请回工作区就行，你还能继续改。老写法是用 reset 加文件名，效果一样。实用组合是先 git status 看现状，精准加想要的，再 status 确认一遍。不确定就一个文件一个文件加，等熟练了再用加目录。

42. 为什么 add 之后还要 commit？一句话讲清暂存到底拦了什么？

很多人觉得 add 完直接存库不就完了，要暂存区这个中间层干嘛。答案就一句：让你能分批、有逻辑地记录历史。Git 管文件像拍照存档，分三层。你正在改的普通文件夹是工作区，Git 还没管；你挑出来准备存档的清单是暂存区；真正永久保存历史的地方是版本库。流程是工作区经 add 进暂存区，再经 commit 进版本库。

暂存区的价值在于：你改了十个文件，但这次只想提交其中三个相关的，就只 add 那三个。它让历史不再是一团乱麻，变成一段段有主题的快照。记住一个坑：只改了没 add 就直接 commit，这次提交里根本没有你的改动，因为 commit 只认暂存区。随时用 git status 看文件现在在哪个区，是新手最该养成的习惯。把三层关系和拍照存档类比记牢，后面每遇到 add、commit 你都能一眼看穿文件此刻在哪一层。

43. git status 里那些红绿文件到底代表什么，怎么看才不慌？

git status 是每次不确定下一步干啥时最该敲的命令，它会用大白话告诉你现在在哪、手里拿了啥。屏幕上的颜色是在提示文件的状态。红色通常代表还没被留意，也就是改了但没进暂存区；绿色通常代表已经进暂存区、等着被提交。你不用记复杂定义，只要看懂我现在有哪些改动、它们准备好提交了没有就行。它还会告诉你当前在哪个分支，有没有改了但没 add 的文件，有没有 add 了但没 commit 的文件。每次提交前后敲一下，心里就有底。

除了 status，还有几个探照灯：log 翻历史账本，diff 看还没提交的差别，提交前最后检查能避免误传密码，show 放大看某一笔提交。新手把东西搞没了也别慌，多数能靠 reflog 这个操作黑匣子找回来。先 status，再动手，是稳的基本功。

44. 提交之后发现改错了，但不想留撤销记录，有干净的办法吗？

如果你担心撤销会留下难看的痕迹，那 revert 正是为你准备的。它不会撕掉原稿，而是在历史上贴一张更正声明。具体说，revert 会新建一笔提交，内容是反着改那次操作。原来的那次提交依然完整保留在历史里，只是它的效果被新提交抵消了。所以历史是干净的、连续的，别人看得到你做了什么、又更正了什么，不会出现一段被抹掉的空白。这在团队项目里尤其重要：大家共享同一段历史，你直接撕掉某次提交，别人的记录就对不上了。用 revert，谁都不受影响。对比一下：reset 那种危险操作才会真的抹掉历史，而且已推送的提交别用 reset 乱改。拿不准就默认选 revert，它永远不会丢历史，是最不容易闯祸的那个。公开的历史用 revert，私下的草稿才 reset。

45. 同一文件两人都改了，我的改动被覆盖，怎么提前避免？

先说清楚一个事实：正常走 Git 流程，你的改动不会被静悄悄覆盖。Git 遇到两人改了同一处，不会擅自选边，而是把冲突摆出来让你定。真正出问题，往往是因为合并前没先拉取最新代码。避免被覆盖的关键动作就一个：在合并或推送之前，先 pull 把别人最新的改动拉下来。如果这时候发现同一行两边都改了，Git 会标记冲突，你手动决定保留哪边，而不是某一方被无声吞掉。养成习惯：动手前先 git status，合并前一定先 git pull，否则可能把别人的新代码覆盖，或者凭空多出不必要的冲突。如果你是一个人用、不跟任何人协作，几乎不会碰到覆盖问题；覆盖只在多人同时改同一处、又没先同步时才发生。万一已经冲突了也别怕，那不是错误，是 Git 在求你做决定。读标记、留对的、删标记、提交，四步就能解决。提前拉取，比事后救火轻松太多。

46. 跟着教程走却总在首次推送卡住，最常见的三个断点在哪？

首次推送卡住，翻来覆去就是三个断点。第一个：not a git repository。报这个错，多半是你不在仓库文件夹里，敲命令前先确认当前目录对不对、里面有没有那个隐藏的 .git 文件夹。第二个：push 被拒，提示 non-fast-forward。意思是 GitHub 上有你本地没有的新提交，通常是别人先传了。解决很简单，先 pull 拉下来合并，再 push 上去。第三个：认证失败，总让你输密码。这不是密码记错，是 GitHub 早已不支持密码登录命令行，得换成 SSH 密钥或者 Token 才通。这三个几乎人人都踩过。顺带一句心法：遇事不决先 git status，再 git log，信息都在里面；不确定的操作先在测试仓库试一次。大多数所谓的卡住，看清报错里的关键词就能定位。

47. 拉取别人代码报 unrelated histories，这句话到底在说什么？

这句话说的是 Git 拒绝合并两段没有共同祖先的提交历史。最常踩的坑：你本地 git init 提交了几次，又去 pull 一个在 GitHub 上已经带 README 的仓库，两边各有各的根，Git 不敢盲合。从 Git 2.9 起，merge 和 pull 默认就拒绝这种合并，属于一道安全护栏，怕你手滑把两个无关项目糊到一起。

明确要合就加一句：git pull origin main --allow-unrelated-histories（分支叫 master 就换 master）。加这个 flag 等于告诉 Git 我知道它们无关、照样缝起来。根治办法更简单：在 GitHub 建空仓库、别勾初始化 README，或先 clone 再放文件，从根上避免两条独立历史。

48. 多人协作时我 push 被拒、提示先 pull、pull 又冲突，死循环怎么破？

这不是死循环，是流程没走完，按固定顺序就能破。很多新手以为卡在死循环，其实是把三步拆开看，每一步都像在报错，合起来却是正常的协作节奏。push 被拒，提示先 pull，说明远程有你本地没有的新提交。别慌，先 pull 把那些拉下来。pull 的本质是先把别人的改动合并进你的本地，这一步如果两人改了同一处，就会冒出冲突标记。冲突不是错误，是 Git 在求你做决定。你打开冲突文件，删掉那些标记、保留想要的版本，再把文件加回暂存区、提交一次，合并不算完成。冲突解决完，再 push，这次就能上去了。记住链路：被拒就 pull，pull 冲突就解决冲突，解决完再 push。合并前一定先 pull，否则可能覆盖别人的新代码。只要一步步走完，所谓死循环根本不会出现，它只是没走到底的中间态。

49. clone 下来是空目录，明明网页上明明有一堆文件？

先别急着自己背锅。clone 下来是空的，最常见的一种情况是：你 clone 的这个仓库本身就没有任何提交，也就是空仓库，Git 会明确提示你 cloned an empty repository，那不是你操作错，是源仓库真没内容。另一种情况是分支没对上。一个仓库可能有多个分支，网页上你看到的那堆文件，可能在某个非默认分支上。clone 默认只把默认分支拉下来，你可以用切换分支的方式去看其他分支有没有内容。还有一种可能：你 clone 的地址根本不是你想的那个仓库，链接抄错就会拉到一个不相干的空地方。排查顺序很简单：先看 clone 时的提示有没有 empty repository 字样，再确认地址对不对，最后检查网页上那些文件在哪个分支。绝大多数空目录都能用这三步定位，不是你弄丢了文件。

50. 仓库突然显示无法访问或 404，是我被封了还是链接错了？

先稳住，绝大多数 404 不是你被封了，是链接或仓库本身的问题。

从平台返回的信息看，404 通常对应的就是路径不对：你访问的 owner/repo 这个地址写错了，或者那个仓库压根不存在。常见情形是仓库被改名、被删除、被设为私有，或者你抄的链接少了一段。你可以先自己验证：把地址贴到浏览器无痕窗口打开，看是不是所有人都不通；对比一下仓库主页的地址格式，确认 owner 和 repo 两段都拼对了。如果是私有仓库，没被授权的人看到的就是 404，这不代表你账号异常。真正账号被封的情况很少见，而且通常会有明确的封禁提示，不会只给一个 404。所以遇到 404，先查链接和仓库状态，别急着怀疑自己被封。确认地址无误、仓库存在且对你可见，问题基本就解了。

51. 误删了 .git、分支弄丢代码、改错分支，这些翻车怎么救？

这三类翻车各有解法，但先记一句通用心法：大多数丢代码都能靠 reflog 找回来，别 panic。误删了 .git 文件夹，本地版本历史就没了。如果之前已经推送过 GitHub，还能从云端重新拉回来，把损失降到最低；没推过的话，工作区里现存的改动还在，只是历史断了，重新初始化接着用。

分支弄丢代码，或者提交到了错误的分支：切到正确分支，用 cherry-pick 把那次提交原样搬过去就行；如果是改错分支又没提交，用暂存改动、切分支、恢复改动的方式转移，干净利落。误用 reset 之类丢了提交，立刻用 reflog 找到那个提交号再 reset 回来。reflog 是你的操作黑匣子，连硬删的提交都留着记录。所以翻车先别慌，先想我有没有推送过、用 reflog 能不能找，多数都能救。

第四章 · 怎么搜到好项目、判断靠不靠谱、让它跑起来？

搜到、判断、跑起来，是从围观者变成使用者的三道坎。前面你会逛、会存，但真要用一个项目，才发现搜出来的结果浩如烟海，点进去一半看不懂，好不容易下载下来又卡在跑不起来。这一章专治这种卡顿：怎么用对搜索语法把噪音滤掉，怎么三眼看穿一个项目是不是还活着，怎么不用碰命令行也能把别人的成果在本地或云端跑通。目的是让你从收藏家变成真用家。

52. 想找个能用的工具，在 GitHub 怎么搜比百度准十倍？

新手最常犯一个错：在百度搜「GitHub 好看的项目」，结果点进去全是别人嚼过的二手推荐和营销软文，还可能带推广。其实 GitHub 顶部那个搜索框直接输关键词（比如 todo app、爬虫、机器学习）回车就是仓库结果，源头项目一站直达。结果页还能切到 Code、Issues、Topics 标签，分别找代码或讨论，比瞎逛高效得多。

举个例子，想找记账工具，搜 expense tracker 直达仓库，比百度「好用的记账软件」准，后者翻半天全是测评。搜索本身免费不限次，多试几个词就能逼近你要的东西。用熟了你会发现，很多工具的官方仓库比任何测评都诚实，版本、更新、讨论全摊在那，一眼能辨真假。一句话：找源头项目直接上 GitHub 搜，别绕去百度转一手。

53. 搜索时加 awesome 前缀，为什么能搜出宝藏清单？

在 GitHub 搜项目时，加 awesome 前缀能翻出一类特殊仓库：它们不装代码，而是一份份精心整理的清单，把某个领域最好的工具、教程、资源按主题罗列好，每条往往配一句说明。比如搜 awesome java、awesome machine-learning，出来的常是社区维护的学习地图或神器合集。对新手特别友好，因为别人已经帮你筛过一遍，照着清单挑比一个一个搜省事。除了 awesome 清单，也可以逛 github.com/trending 看最近涨星最快的项目，按天、周、月切换，发现新技术新轮子。提醒一句：清单也是人维护的，挑出几个真用得上的再深入，别又被清单本身的体量淹没。清单质量参差，挑 star 高、近期还在更新的那份，作者越用心，链接越靠谱。

54. 一个项目值不值得用，看 star 数就够了吗，还有哪些信号？

Star 数只是最表面的信号，代表曾经有多少人点过喜欢，不代表现在还好用。更该看几个维度：pushed 时间（最后一次更新是什么时候，久不更新可能已弃坑）、Forks 数（被复印去改的次数，反映实用程度）、Topics 标签（归在哪个领域）、开源许可证（能不能商用）。组合着看最准，比如限定 language:Python stars:>10000 pushed:>2024-06-01，出来的基本都是又活跃又靠谱的精品。还可以加 archived:false 排除已归档的死仓库。单看一个数字是会看走眼的，多扫几个指标再决定要不要投入时间，比凭感觉靠谱。如果犹豫，就把候选并排看这几个数，谁更新勤、谁协议友好，答案常常自己跳出来。

55. 怎么一眼看出一个项目是活的还是早就弃坑了？

判断存活看一个核心指标：pushed，也就是这个项目最后一次推送代码的时间。仓库主页会显示最近活动，搜索结果也能按 pushed 过滤。如果最近一两个月还有提交，说明有人在维护，你提的 Issue 大概率有人理；如果最后更新停在几年前，多半已休眠甚至弃坑，遇到问题基本找不到人。

Star 数高不代表活着，很多老牌项目星标惊人但早已停更。简单记：先看更新时间，再决定要不要投入时间学它。一个还在持续更新的项目，你踩坑了也更容易找到解法，维护者还可能接纳你发现的 bug。所以挑项目先把最后更新当第一道筛子，不新鲜的再好看也先放一边，更新勤才有人管，停更项目连踩坑都没人兜底。别被高 star 骗了，点开看一眼最后提交日期，半分钟就能排除大半死项目。

56. 项目 README 写得太专业看不懂，普通人有没有速读套路？

README 再专业，结构也大致固定，按这个顺序扫就行。开头看项目名和一句话简介，搞清楚它到底是干嘛的；往下找 Installation（怎么装）和 Usage（怎么用），这两段是你真正要动手的部分；再找 Examples 或 Demo，看它跑起来长什么样；最后看 License，确认能不能用、能不能改，以及能不能商用。规范的 README 通常含这几块：项目名与简介、安装、用法、示例、许可证、贡献者联系方式。看不懂代码块别慌，普通用户只要读懂这几段文字说明就够判断了。英文 README 也可以整段丢给翻译或 AI 帮读，不用逐词啃。能读明白这四块，项目适不适合你就清楚了，这四块读完你基本就能判断值不值得继续花时间，不必硬啃代码。

可复制模板（直接复制使用）：读别人 README，按这个顺序找最快：□ 开头一句话：这项目是干嘛的？□ Installation / 安装：怎么装？□ Usage / 用法：怎么跑起来？□ Examples / 示例：有没有现成例子？□ License / 许可证：能不能商用？找不到就直接看 Examples 和 Usage，最省时间。

57. 拿到一个项目想跑起来，第一步该看 README 的哪个段落？

想跑起来，第一步永远看 README 里的 Installation（安装）那段。它通常会写明你需要先装好什么运行环境，以及粘贴即可用的安装命令。装好之后，再看 Usage（用法）那段，里面一般是最小可运行的例子，照着敲一遍就能看到效果。很多项目还会把快速开始放在最顶上，优先看那段。如果一份 README 连安装要求都不写，本身就是 usability 红灯，普通用户上手会很吃力。很多人一上来直接 clone 然后乱试，结果卡在环境没配好。记住顺序：先读安装要求，确认本地条件满足，再照用法示例跑。README 写得规范的项

目，这两段就是你上手的地图，别跳过。把安装段读透，后面九成问题都出在环境没满足这一条上，提前看清最省事。

58. 别人项目里 npm install / pip install 是啥，看不懂也不敢乱敲？

这两条是装依赖的命令，出现在 README 的安装段落里。一个项目很少把所有用到的第三方库都打包进来，而是列一份清单：npm 项目写在 package.json，Python 项目写在 requirements.txt。npm install 和 pip install 就是按这份清单，把需要的库下载安装到你的电脑上，是跑项目前的标准准备动作。不敢乱敲很正常，但这是常规操作，前提是你从项目官方 README 复制、且项目本身可信。它们只装依赖，不会删你文件。如果你跳过这步直接跑，往往会报缺模块的错误，项目起不来。照着 README 装，比自己瞎找库稳得多，是跑通别人项目必经的一步。说白了，它俩就是按清单备料，料备齐了项目才跑得起来，再正常不过。可复制模板（直接复制使用）：# Node / JavaScript 项目 npm install # Python 项目 pip install -r requirements.txt

说明：项目自带依赖清单（package.json / requirements.txt） # 跑上面这条，依赖就自动装齐了

59. README 里那串安装命令在自己电脑报错，多半是哪里的问题？

安装命令报错，八成出在本地环境没配齐。很多项目 README 的安装段会写明前置要求，比如要装某个版本的 Node 或 Python，你本地没装或版本对不上，命令就会失败。有些项目对版本很挑剔，会写「要求 Node 18 以上」之类，对着看最稳妥。另一种常见情况是命令要在项目目录里敲，你还在别的文件夹，它找不到清单文件。网络不稳也会导致下载依赖中断。排查顺序：先确认前置环境装没装、版本对不对，再确认你站在正确的项目文件夹里，最后看是不是网络问题。报错先看 README 有没有写清楚环境要求，别急着怀疑项目本身。README 写清楚的照做就行，写模糊的多半作者自己也没测过你的系统。实在查不出，就把完整报错和系统版本一起贴去项目 Issue 搜，别人多半遇过同样的坑，别自己闷头瞎试。

60. 把项目网址里的 github 换成 deepwiki 就能看人话文档，真的吗？

真的，而且免费、不用登录。操作就一步：把仓库网址里的 github.com 换成 deepwiki.com，比如 github.com/facebook/react 变成 deepwiki.com/facebook/react，打开就是 AI 生成的互动文档，带架构图、模块说明，还能直接对话问它这段代码干嘛用。它背后是扫描公开仓库的代码和 README 自动生成，适合你读不懂源码、又想快速搞清一个项目是啥的时候。注意两点：它只分析公开仓库，没索引过的库首次要等几分钟；私有库得登录授权。把它当读代码的翻译官，比硬啃源码省太多时间。它已经索引了数万个热门公开库，冷门库第一次访问会现场分析、等几分钟就好，不影响你之后随时回看。可复制模板（直接复制使用）：原链接：https://github.com/owner/repo 换成：https://deepwiki.com/owner/repo 把 github.com 换成 deepwiki.com，其余路径不变，就能看到用大白话讲解的文档。

61. 看不懂代码逻辑，把整个 README 丢给 AI 让它讲，靠谱吗？

靠谱，而且这是非技术读者最省力的读法。README 本身是给开发者写的，夹杂命令和术语，但你把整段贴给 AI，让它用大白话讲这个项目干嘛的、你要不要装、怎么装，效果很好。更好用的是连仓库地址一起给，让 AI 先读 README 再回答你的具体问题，比如第三步那个命令是干嘛的。也可以只贴某一段，问「这段意思是让我先装什么」。注意 AI 可能概括错细节，关键安装步骤仍以 README 原文为准，别被它自信的语气带偏。把它当翻译和答疑助手，别当唯一真理来源。读懂了再决定要不要动手，能少走很多弯路，也比硬啃英文文档轻松。这种边问边读的方式能让你半小时摸清一个项目的门槛，再决定值不值得动手，省下的时间比硬读划算。读不懂就问，问完再动手，比赌运气乱跑稳。

62. 下载一个项目卡在 20KB/s，除了干等还能怎么加速？

国内直连 GitHub 慢，根因是网络链路和域名解析的问题，干等最亏。最省事的一招是改 hosts，用社区维护的每日自动更新源替换域名解析，零安装、刷新一下 DNS 就生效。不想动手可以换镜像站域名，把 github.com 换成镜像前缀 （如 kkgithub.com），浏览器里直接能开。

大仓库 clone 卡，把 https 地址换成 ssh 地址往往更稳。还有本地代理类工具和浏览器重定向插件可选。选一层能解决就够，别把所有招都堆上，简单才是能坚持用的方案。纯静态资源（图片）的加速另有 CDN 方案，那是另一层，不混为一谈。关键是别卡在一招上死等，换条路往往立刻通畅，网络问题本来就该多手准备，灵活比执着有用。今天这招慢就换明天的招，别死磕一个入口。

63. 项目说要申请 API key 才能跑，这东西去哪弄、安全吗？

很多调用外部服务的项目（尤其是 AI 类）需要一把 API key 作为身份凭证。去哪弄：看项目 README 指的那家官网注册申请，公开仓库搜一下项目名通常能找到入口和免费档说明，多数新服务都有免费额度，个人试玩够用，别一看到要 key 就退缩。安全上记住一条铁律：key 这种凭证绝不写进你要提交的文件里，更别上传到公开仓库。本地跑就把 key 放在环境变量里，比硬编码在代码里安全得多。这也和 SSH 密钥一个道理，私钥只锁自己本机，绝不外泄。拿到 key 先在小项目试，确认逻辑跑通再扩大使用。免费额度对个人试玩通常够用，真跑通了再考虑升级，别被要 key 三个字劝退，凭证这东西管好它和管好密码一个道理，心思到了就不慌，凭证管理本就是基本功。

64. 想在手机或网页直接试跑、不想配本地环境，有办法吗？

有，GitHub 自带一个叫 Codespaces 的云端开发环境，不用在你电脑装任何东西。在仓库点绿色 Code 按钮，切到 Codespaces 标签，新建一个就能在浏览器里打开一个带完整环境的编辑器，直接照 README 跑项目。它等于借了台云上的电脑，预装了项目需要的环境。它按使用时长计费，但个人有免费额度，日常试玩基本花不到钱；不用时记得关掉，闲置也会计时，默认半小时没操作就会停。适合临时想试一个项目、又不想折腾本地环境的场景。手机上也能开，只是屏幕小操作费劲，应急够用。它比在自己电脑折腾半天装环境省事太多，尤其想先验证一个项目值不值得深玩时，试错成本几乎为零，云上环境用完即弃还不占本地空间。拿不准要不要入坑时，先上去探一探最划算。

65. 项目跑起来一堆红字报错，怎么判断是项目问题还是我的问题？

先分两类：红字如果提示缺某个运行环境、某个包装不上（常带 command not found、module not found、no such file 这类字眼），多半是你本地没配好，属

于你的问题；如果是代码逻辑错误的 traceback、明确说某功能不支持或版本不兼容，更可能是项目本身或它要求的场景你没满足。最快的判断法：把报错里的关键那句复制去项目 Issues 里搜，看有没有人提过一样的。开源项目里别人踩过的坑基本都留在 Issue 里。如果搜不到、又是环境类报错，先从自己的环境配置查起；确认环境对了还报，再考虑是不是项目本身有 bug 或你用的系统不被支持，那时才去提 issue。先把自己这头排查干净，再去找作者，既省时间也显得你不是上来就甩锅。

66. 别人仓库的 Releases 和直接下载代码，普通用户该点哪个？

普通用户想用现成东西，优先点 Releases。Releases 是作者基于某个版本 （Tag）打包发布的正式包，常常直接是可执行文件或安装包，下载就能用，不用自己配环境编译。而直接下载代码（Download ZIP 或 clone）拿到的是当前最新源码，你要自己装依赖、跑命令才能用，是给想读源码或二次开发的人准备的。一句话：想用，去 Releases 找安装包；想学或想改，才下源代码。对不想碰命令行的人来说，Releases 才是友好入口。注意 Download ZIP 拿到的是最新源

码，未必是稳定版，而 Releases 通常对应作者打过标签的可用版本，更稳。普通用户记住这条就够了：要用就奔 Releases，要看源码才碰下载代码，别搞反。可复制模板（直接复制使用）：# 打标签并推送到 GitHub git tag v1.0 git push origin v1.0 # 然后在仓库的 Releases 页面 # 基于这个 Tag 发布，可上传安装包供别人直接下载

67. 不想碰代码又想用现成项目，怎么挑开箱即用的版本？

找开箱即用版本，就盯 Releases 页面里带 Assets 的那几个文件。作者通常在那里上传编译好的可执行程序或安装包，文件名带你的系统标识（比如 Windows 的 exe、mac 的 dmg、Linux 的 AppImage），下载双击就能跑，完全不用碰代码。挑的时候认准三点：对应你电脑系统、标注了版本号、更新时间较新。下错系统的包打不开，所以先看清楚标识。避开那些只有源码、要你自己敲命令安装的版本。如果 Releases 里没有你系统的包，说明这项目暂时只适合会技术的人，普通用户可以先收藏等官方出包，或看有没有网页版 demo。一句话，能下到安装

包就别碰源码，普通用户目标是用起来，不是学会编译。省下的精力留给真正用项目解决问题。

68. 怎么判断一个 AI 项目是噱头还是真能落地帮我干活？

别只看标题和效果截图，看三件硬指标。第一，README 有没有真实可跑的安装和使用步骤，而不是只放一段炫酷视频；连环境要求都不写的项目，基本没法落地。第二，看最近更新时间（pushed），AI 领域几个月不更新就可能已过时，文档和需求都变太快。第三，看 Issue 里大家在讨论用法还是全是跑不起来，前者说明真有人用，后者是预警；再顺手看 Contributors 是否还在活跃。标题猛喊一键、全自动却没文档的，多半是噱头。真正能落地的项目，会把你需要什么、一步步怎么做写清楚，不靠一张图唬人，文档和活跃度都骗不了人。多花三分钟看这几处，比被一张炫图种草后失望强得多，冷静看指标，噱头项目自然现形。筛选成本低回报高，值得花这三分钟。

69. 收藏了一堆好项目但从不打开，怎么建立找了就用的习惯？

囤项目是新手最常见的假努力。有句话很扎心：看十遍教程不如自己动手传十个仓库，找项目也一样。改掉习惯的方法很简单：每次只认领一个当下真要用的项目，立刻照它的 README 跑一步，哪怕只是把它 clone 下来打开看一眼，也比囤一百个强。别搞收藏夹吃灰那套，给每个收藏加一句我打算用它做什么，没有具体用途的就别收。也可以每周清空一次收藏，只留这周真打开过的。找了就用，用了才算真的学到，囤着不动只是在自我安慰，时间久了连当初为啥收都忘了，反而增加焦虑。收藏本是为了日后用，不是凑数好看，每收一个就问自己这周会打开吗，答不上来的别点星，让收藏夹只装真正要用的东西。轻装上阵比满仓吃灰强得多，想通了这点，囤积癖自然就淡了。

第五章 · 怎么把我的东西存好、秀出来、甚至参与开源？

存好、秀出来、甚至参与开源，是从使用者变成建设者的三步。前面你会搜、会跑，但 GitHub 真正值钱的地方，是它能把你的东西稳妥存好、把你的能力公开秀出来、还能让你和世界上的陌生人一起把项目做下去。这一章不假设你懂代码，只讲普通人也用得上的存、秀、参与三件事：怎么放第一个仓库、怎么用 Pages 做主页、怎么不写代码也能给开源做贡献。

70. 我的第一个仓库该放什么，空仓库会不会显得很菜？

很多人纠结第一个仓库放什么，怕空着显菜。其实 GitHub 本身就把你的主页当成活简历，哪怕是学校作业、练手小项目，传上去都比空着强。第一仓库可以放一份自我介绍、学习笔记，或者你照着教程做的小练习。重点是先有，再慢慢丰富。提醒一句：GitHub 默认公开，仓库不想给人看就在建的时候选 Private。空仓库不丢人，一直不敢建才可惜。先传一个再说，主页是滚雪球，越早开始复利越大。

哪怕只是整理的一份书单、一段学习记录，传上去也是在积累数字足迹，比只想不做强。别等准备好了再开始，第一批观众就是未来的你，回看这些起步记录，比任何教程都更清楚自己走了多远。很多人第一份仓库就是学习笔记，几个月回看，连自己都惊讶进步有多大。

71. 怎么写一份让人一眼看懂的 README，不用会排版也能好看？

README 是仓库的门面招牌加说明书，GitHub 会自动把它显示在首页，写好性价比极高。不用会排版：GitHub 用 Markdown 这种简单格式，网页里点开文件右上角铅笔就能改，编辑框上方有 Preview 能先看效果再保存。照着清爽模板填就行：功能介绍、使用方法、联系方式三块，把话说清楚比好看重要。写完后别人点进来第一眼就知道这是啥、怎么用，省去一堆提问。记住文件必须叫 README.md，GitHub 才认，文件名写错它就当普通文件不渲染。写不漂亮没关系，写清楚就赢了一大半，读者要的是信息不是排版大赛。模板到处都有，搜 resume template 或 github readme template 就能找到，复制改改比从空白页憋字快得多。可复制模板（直接复制使用）：

README 模板： 项目名一句话介绍这个项目是做什么的。 ## 功能介绍

• 功能一- 功能二 ## 使用方法1. 步骤一2. 步骤二 ## 联系方式有问题欢迎提 Issue！### 72. Markdown 语法那么多，写 README 只要先掌握哪几个就够？

72. Markdown 语法那么多，写 README 只要先掌握哪几个就够？

写 README 真用得上的就四个：# 加空格写标题、把文字用两个星号包住变加粗、用减号开头做列表、用反引号包住代码。这四个覆盖九成场景，标题分明、重点突出、条目清楚，普通读者一眼就读懂。进阶再学链接和图片：方括号加圆括号插链接，感叹号加方括号加圆括号插图片。记住一条铁律：# 后面必须空一格，写成 #标题是不会变大的。文件必须叫

README.md，GitHub 才认。新手别被语法吓住，先会这四个，剩下的用到再查完全来得及。网上有现成的 Markdown 速查表，存一份在手机里，写到卡壳时瞄一眼就行，不必背。把格式当工具，别当门槛，真正卡住新手的从来不是语法，是怕写错，其实改了再存随时能改。而且 Markdown 写出来的字在哪打开都整齐，不像 Word 换个电脑就乱排版，这点对新手特别友好。可复制模板（直接复制使用）：# 大标题 （# 后面空一格） ## 小标题 加粗文字

• 列表项 一行代码 链接文字 多行代码：用三个反引号包住，后面写语言名（如 python）

73. 想把代码传上去又怕写得太烂被笑，第一份仓库怎么包装？

怕被笑是多虑了。GitHub 上看的是你愿不愿意动手，主页活跃整洁比写得多华丽更有说服力。包装第一份仓库很简单：套一个清爽模板，功能介绍、使用方法、

联系方式填清楚；标题层级用 # 拉开；改完用网页的 Preview 先看渲染效果再保存。不用追求酷炫，把项目是干嘛的、怎么跑起来写明白就够。哪怕只是练习，传上去也是你成长的证据，没人会笑认真起步的人。反而一个空空如也的主页，才容易让人觉得你只是围观。社区看的是态度不是天赋，敢传第一份的人已经胜过大多数只看的。主页是成长日志，不是摆出来给人看的成品作品集，越早留痕越能看出进步，完美主义才是第一仓库最大的敌人。实在没灵感，就去搜几个高 star 的练手项目主页，照着它们的结构抄框架，比自己空想快得多。

74. GitHub Pages 是什么，怎么把仓库变成个人主页或简历？

Pages 是 GitHub 自带的免费静态网页服务，能把你的仓库变成一个能通过网址访问的网站。常见用法就是做个人主页或简历：把写好的网页文件传上仓库，在 Settings 里开启 Pages、选好分支和文件夹，就能用用户名.github.io/仓库名这个地址访问。它特别适合放简历、作品说明页、文档。比起 PDF 简历，在线网页能展示技术、方便分享、随时改随时生效，面试官点个链接就能看。对不想碰复杂建站工具的人来说，Pages 是把仓库变公开作品集最省事的一招。你不必是前端高手，网

上简历模板一大把，下载改文字传上去就能用，Pages 只负责帮你发上线，展示自己这件事的技术门槛被它压到了最低。有人甚至用它托管课程表、读书清单这种小东西，反正免费，多一个公开入口就多一份被看见的机会。可复制模板（直接复制使用）：

# 1. 新建仓库，名叫：用户名.github.io
# 2. 上传下面的 index.html
# 3. Settings → Pages 选分支，访问 https://用户名.github.io

<!DOCTYPE html>
<html>
<body>
<h1>你好，我是 XXX</h1>
<p>这是我的 GitHub 主页</p>
</body>
</html>

75. 用 Pages 搭个人网站要买服务器和域名吗，普通人够用吗？

不用买。Pages 本身就是免费托管，还自带一个用户名.github.io 的域名，仓库开好 Pages 就能直接用，服务器和域名都省了。它只支持纯静态网页（HTML、CSS、JS），不能跑后台程序，但做简历、作品集、说明页完全够用。

如果你以后想要自己的个性域名，可以另外绑定，但那是加分项不是必选项。对普通人来说，零成本先跑起来，比纠结域名实在得多。很多人卡在想买域名这一步，结果网站一直没建。先用地带 github.io 跑满一个月，真有人看了再考虑个性域名，顺序别反了，免费方案撑得起绝大多数个人展示需求，别为枝节耽误正事。真要升级，等主页有了稳定访客再谈也不迟，那时候你才知道自己到底需要什么功能。很多人用 github.io 域名跑了一两年都没换，也照样凭主页拿到面试机会。

76. 怎么让我的主页在 recruiter 搜我名字时排到前面？

GitHub 主页和你的用户名.github.io 网站都能被搜索引擎索引，所以第一步是把主页链接放到你能控制的地方：简历、博客、社交简介都填上，别人搜你名字时这些结果会冒出来。主页本身要容易被搜到，靠的是内容完整。每个仓库写清 README、挑几个代表作置顶或加描述，主页就显得有料。与其研究排名技巧，不如把主页做得活跃又清楚，HR 常直接看 GitHub，一个整洁的主页比简历上写熟悉编程有说服力。也可以把主页链接写进邮件签名和简历页眉，凡是能留联系方式的地方都放，主动出现在别人视线里比等搜索更靠谱，曝

光是做出来的不是等来的，多放几个入口总没错。顺手把 GitHub 主页链接在领英也填一份，海外招聘方同样会顺着它来翻你的作品。

77. 怎么把 GitHub 主页弄酷炫（动态统计/模板），10 分钟搞定？

GitHub 上有大量现成的个人主页模板和动态统计卡片，不用自己从零设计。搜 github profile readme template，能找到带语言占比、连续贡献天数这类动态卡片的模板，复制下来改改名字和信息就能用。原理是这些卡片读取你公开的贡献数据自动生成图片，放进主页的 README 里就会动。十分钟足够套一个能看的版本。普通用户别追求复杂，选一个简洁模板，比花几小时调样式更值得。这些模板大多开源免费，挑一个 star 高、近期还在更新的，作者维护得好你才少踩坑。别贪多，酷炫是结果不是目标，内容持续更新自然会有人觉得你酷，主页一眼能看懂比花哨重要。卡片更新靠的是你持续提交，所以与其折腾样式，不如保持每周动一动仓库，数据自然好看。

78. 看到喜欢的开源项目想帮忙，但完全不会写代码能贡献什么？

能贡献的远比你以为的多，而且不写代码也行。文档错别字、翻译、把使用步骤写得更清楚，都是实打实的贡献；发现 bug 提个清楚的 Issue、帮忙回复新手问题、做设计或写教程，维护者都欢迎。开源项目最缺的，常常是谁来帮它变得更好懂、更好用，写代码反而是其次。从你最擅长的入手：文笔好就改文档，细心就报 bug，会设计就做图。不少项目专门开 welcome、help wanted 这类讨论区招人帮忙，你哪怕只翻译一段说明也是雪中送炭。开源的善意是互相的，你帮了它，它也让你的名字出现在贡献者里，这种正向循环正是很多人留下来的原因。很多项目还专门设了文档小组，连例会都对新人开放，你不是一个人单打独斗，缺什么直接问，社区本来就欢迎伸手的人。

79. 改错别字、补文档算不算贡献，作者真的欢迎吗？

算，而且这是门槛最低、最不容易被拒的贡献。很多项目的文档和示例代码里都有错漏，维护者自己改不过来，你顺手修一个错别字、补一句没写清的说明，他们求之不得。开源协作里，文档贡献和代码贡献一样被尊重。别觉得小事不值一提，积少成多项目才更好用。第一次提 PR 就从改文档开始，流程跑通了，以后再碰代码也不慌。维护者最怕的，是没人愿意伸手，你改得少没关系。很多大项目的第一份贡献就是改文档，维护者会在合并时认真道谢，这

种正反馈很上头。你以为的微不足道，往往是别人卡了很久的别扭，门槛低不等于没价值，恰恰相反它最易被需要。维护者常把文档贡献者单独列在致谢名单里，你的名字会和他们一起出现在项目首页，这份认可比点赞实在得多，也是你日后简历上能写的一笔。

80. good first issue 标签是给新手的吗，怎么用它迈出第一步？

正是给新手准备的。很多开源项目会给适合第一次参与的任务打上 good first issue 标签，意思是这个活儿简单、有人愿意带你，专门用来练手。在仓库 Issues 里筛选这个标签，挑一个你看得懂的，按它描述的步骤改，改完提 PR。很多新手友好项目常带这个标签，作者也推荐新人从这里起步。它帮你跳过选任务的纠结，直接进流程，是迈出第一步最稳的入口。筛选时优先看带这个标签且近期有人合并的仓库，说明有人真在带新手，你提了有人理。挑个描述清楚的照步骤做，第一份贡献往往比想象顺，别贪多同时开好几个，先完整走完一个流程最值。走通之后再把经验写成一篇短文发出来，既帮了下一批新手，也给自己留了记录，这份可展示的脚印，比空说我会开源有说服力得多。

81. 我想给别人的项目提建议或报 bug，Issue 怎么写才不被无视？

写好 Issue 有四步：先搜一遍已有的 Issue，避免重复；选对项目提供的模板；写清三要素：现象、复现步骤、你的环境（系统版本号）；加上合适的标签。好 Issue 长这样：标题说清问题，正文写清怎么点、输了啥、预期和实际差在哪。差 Issue 就是一句这软件又崩了，没人帮得了你。记住一个 Issue 只说一件事，和项目无关的怎么学编程该去 Discussions，别搞混。你描述越清楚，别人帮你越快，自己也练了表达。好 Issue 还讲究语气礼貌、附截图，维护者更愿意帮态度好的人，把对方当合作者而非客服，沟通质量直接决定你的问题能不能被解决，写之前先搜已有答案也显诚意。语气上把对方当合作者而非客服，对方更愿意伸手，这点在开源圈几乎是默契。可复制模板（直接复制使用）：【标题】[Bug] 登录按钮在 Safari 下点击无响应 【现象】点击登录没任何反应 【复现】1. 打开首页 2. 点登录 3. 无响应 【环境】macOS 14 / Safari 17 / App v2.3 （一个 Issue 只说一件事，描述越清楚别人帮你越快）

82. 提 Pull Request（PR）到底是在提什么，和直接改文件差在哪？

PR 是向原项目作者递一份改好的作业请他批阅：请把我的改动合并进主仓库。直接改文件，通常指在你自己仓库网页里改，那只影响你自己；而 PR 是协作流程，你先 Fork 出副本、改完发起 PR，原作者审核通过后才会合进原项目，别人也都能看到。所以 PR 多了道审核，正是这道审核保证质量、避免乱改。想给开源做贡献，标准动作就是 Fork 改完提 PR，而不是直接改别人的库。PR 让改动可追溯、可讨论，是开源能大规模协作的基石。直接改自己仓库谁都看不到，PR 却让全世界看见你的参与记录，哪怕改一行走完流程你就是正式贡献者了，信用是开源里最硬的货币。哪怕只是修正一个标点，走完 Fork 改完提 PR 这套流程，你就算正式踏进了协作的门。可复制模板（直接复制使用）：标题：修复登录按钮在 Safari 下的错位说明：

• 为什么改：Safari 下样式错位- 怎么测的：本地 Safari 17 验证通过- 对应 Issue：Closes #123

（一次 PR 只做一件事；说明里写 Closes #编号，合并后自动关 Issue）

83. 我的第一个 PR 被拒了，是不是说明我不行，还是正常流程？

太正常了，完全不代表你不行。Code Review 是请人帮你看一眼再合并，评审针对的是代码不是你这个人，被要求改是很普通的日常。每个资深工程师都被审过成百上千次，收到意见就删库跑路大可不必。把意见当免费指导，逐条回应、改完在同一分支再推，PR 会自动更新，不用重开。PR 本质是一次对话，礼貌沟通、小步快跑就好。很多项目还鼓励多提 PR 练手，被拒后改了重提是常态，没人会记仇。你把每次反馈当成免费的一对一辅导，水平涨得比闷头写快得多，真正卡住新人的不是被拒，是不敢再提第二次。不少开源项目主页都挂着贡献者故事，里面大半人的第一份 PR 都被打回重写过，你一点都不孤单。被拒只是协作流程里最普通的一环，连资深维护者都经常收到修改意见，区别只在于他们改完会再提。

84. 项目里的 Discussions 和 Issues 有什么不同，我该去哪说话？

简单分：Issue 是报修单，管具体的事，比如报 bug、提明确的功能需求；Discussions 是茶水间加公告板，聊想法、问用法、发公告，比 Issue 轻松。答疑和脑洞去 Discussions，明确的 bug 和功能去 Issue，别搞反。两者配合还有 Projects 看板看进度，三件套是 Issue 管事、Projects 看进度、Discussions 聊想法。聊清楚一个需求后，还能一键把讨论转成 Issue 进入开发。新人常犯的错是在 Issue 里问这库怎么用，正确去处是 Discussions 的 Q&A，去对了地方问题才有人接。规矩清楚了，社区对你的第一印象就好，也显得你懂协作的基本礼仪。看板 Projects 还能让你看到自己提的需求排在第几位，等它从待办变完成很有成就感。

85. 想用 GitHub 管理自己的写作、笔记、资料，它比网盘强在哪？

强在它会记版本。GitHub 像代码的保险箱加时间机器，每次保存都是一个节点，你能回到任意历史版本，误删误改都能捞回来，这是普通网盘给不了的。写作用纯文本或 Markdown 最舒服，增删一眼能看出改了哪。担心隐私就建 Private 仓库，默认别人看不到。跨设备同步也方便，换个电脑拉下来就有。对爱写东西的人来说，它是带回溯能力的云笔记，比单纯存文件踏实。而且 GitHub 免费私有仓库额度足够个人使用，敏感笔记放心存。对比来回找备

份、怕文件覆盖，这种确定性对写作者太重要了，长期写东西的人最怕版本乱，它正好治这个。而且纯文本占用极小，几千篇笔记也撑不满一个免费仓库，长期攒着毫无压力，哪天想导出还能打包一把梭带走，不被任何平台锁死。

86. 听说 GitHub 能自动跑任务（Actions），普通人能拿来干什么？

Actions 是 GitHub 里的自动打工机器人，你设定好规则，它就在特定事件触发时自动执行。普通人用得上的场景不少：定时跑一个备份、每天自动发一条内容、推送代码后自动把网页部署上线。它市场里有大量现成模板，很多改改配置就能用，不用自己写复杂代码。比如你想让个人网站每次更新自动发布，挂个现成工作流就行。不用懂原理，会套模板就能省下重复劳动。市场里搜 github actions template 能直接抄，很多连代码都不用读，填几个参数就跑。普通人用它盯个定时备份、自动发周报，零代码也能享受自动化的爽，别被自动化三个字吓到，它本质就是设定好的定时任务。担心写错也不怕，工作流跑挂了只会邮件提醒你，不会动你仓库里任何已有文件。

87. 不会写代码能用 Copilot 命令行帮我操作 GitHub 吗？

能。GitHub 有个 Copilot 命令行工具，你用大白话告诉它想干嘛，它就帮你写出对应的命令，也能反过来解释一条陌生命令是干嘛的。配置好之后有两个短别名最常用：一个负责给建议命令，一个负责解释命令。它执行前会先请你确认，不用担心它乱动。对不熟命令的人来说，这等于多了个随时答疑的助手，不会因为记不住指令就不敢碰 GitHub 的操作。装好之后它常驻在命令行里，想到什么操作直接问，不必再翻教程。对非技术用户，它把 GitHub 从命令行恐惧症变成了聊天式操作，友好度提升一大截，敢问就敢用，这正是它存在的意义。它还能把一长串复杂操作拆成你能看懂的步骤，边做边学，顺手就把命令也记住了，久了你甚至能脱离它自己敲，这才是它真正的价值。

88. 用 GitHub + jsDelivr 搭免费图床，给博客图片做 CDN 加速？

可以，这是很多人的经典玩法。把图片传到一个 GitHub 公开仓库当存储，再用 jsDelivr 这个 CDN 加速访问，博客里直接贴加速后的链接，图片加载更快也更稳。配置不复杂，但有两件事要注意。一是仓库是公开的，别传隐私图；二是仓库别塞太大，体积过了一定量级容易被人工审核甚至清理。对偶尔写博客的人来说，这套免费方案够用，只是别拿它当无限网盘猛灌。也有现成的图床工具能一键上传并自动套好加速链接，不用手动

拼地址。新手用工具省心，记得仓库单独建一个专门存图，别和代码混在一起难清理，定位清晰了这套免费方案就能稳稳用很久。图片多的时候，记得按年份建子目录分类，日后好找也好清理，别全堆在根目录，不然几个月后你自己都分不清哪张是哪张。可复制模板（直接复制使用）：# 把仓库里的图片当外链用（公开仓库） https://cdn.jsdelivr.net/gh/用户名/仓库名@main/图片路径.png # 例：仓库 my-blog 的 images/logo.png https://cdn.jsdelivr.net/gh/my-blog/my-blog@main/images/logo.png

89. 靠开源打赏（GitHub Sponsors）赚钱，真有人做到吗？

真有人做到，而且 GitHub 对这笔钱很大方：平台不抽成，赞助金额百分之百给到开发者。逻辑是，你维护的项目帮到了别人，对方可以通过 Sponsors 直接按月或一次性赞助你，主页会出现一个 Sponsor 按钮。但别误会成随便就能赚：前提是你的项目真有人用、有真实贡献，平台也会审核申请者。它是给持续付出的开源者的一条可持续收入路径，不是新手上来就能变现的捷径。圈子里确实有人靠它获得稳定资助，前提是项目真的解决了别人的问

题、积累了信任。把它看成对你持续付出的回报，而不是流量变现，期望对了路才走得远，先把项目做扎实、真的帮到人，打赏才顺理成章。平台对申请者有审核，所以别一上来就挂按钮，等有了真实用户再开反而更自然。

第六章 · 想更进一步，或该停在哪

走到这章，你已经会搜、会跑、会存、会秀、甚至敢提 PR 了。接下来这条路怎么走，其实没有标准答案：有人继续往分支、自动化深处钻，有人觉得够用就停在这里。这一章不催你进阶，只把几个值得知道的高级功能和哪些事 GitHub 其实不擅长讲清楚，让你自己判断下一步往哪走、停在哪。

90. 上手之后，下一步该学分支管理还是直接学协作？

不用二选一硬着头皮啃。进阶本来就是按目标挑的：想发版本学 Releases，想展示学 Pages，想省重复劳动碰 Actions。分支是协作的底座，但你不必先学透它，直接从 Fork 项目、挑 good first issue、提 PR 开始，分支怎么用会在实战里自然懂。比起按课本顺序挨个学，先想清楚自己要用 GitHub 干什么、再针对性往下走更划算。教程看十遍，不如传十个仓库练出来的手感实在，持续用起来才是正路。官方给的进阶地图是 Tag 打版本、Releases 发版、Pages 展示、Actions 自动化、参与开源，你能看出分支并没有单独占一块，它早就嵌在协作每一步里。所以与其纠结先学哪个，不如直接进一个真实项目，需要什么现学什么，这种选法比啃概念书省力得多。

91. 多人项目里 Code Review 到底在审什么，新人怎么不被挑刺？

审的是逻辑对不对、有没有漏掉边界情况、会不会引入新 bug 或性能问题、命名注释清不清楚。关键一条：评审针对的是代码，不是你这个人，所以别 defensive，把意见当免费指导就好。新人最该记住：大 PR 没人愿意审，一次改动控制在能审完的体量；收到意见逐条回应、改完推同一分支自动更新，不用重开。把 Review 看成两个人一起把事做对，被提意见是有人帮你兜底，是好事。好的评审会给出具体建议，比如这里用循环可读性更好，而不是只丢一句这写得什么玩意；用 Suggestion 功能还能直接给修改片段让作者一键采纳。结论无非三种：可以合并、有想法但不阻塞、必须改完再合并。你作为提交者，不认同的地方礼貌说明理由就行，不是所有意见都得照单全收。

92. Projects 看板能当项目管理工具用吗，比 Excel 强在哪？

能，而且和代码任务天然打通。看板把 Issue 和 PR 当便利贴，拖到待办、进行中、已完成，进度一眼可见；还能加负责人、截止日期、优先级字段，切表格视

图筛选。它底层还是 Issue/PR，删了看板也不影响原任务，这点比 Excel 安心，你不用再来回把任务状态同步两份。对个人待办、版本发布跟踪、轻量规划都够用，比纯表格多了和代码绑在一起的实时感，协作项目里尤其顺手。记住看板卡片每次开工、完工都拖一下才有意义，不然它很快就过期。它和 Discussions、Issues 组成协作三件套：Issue 管事、Projects 看进度、Discussions 聊想法，三者配齐协作不迷路。比起 Excel 你还要手动把状态搬来搬去，看板直接从代码仓库拉任务，省掉那层同步的功夫。

93. Actions 自动构建、部署听起来高级，新手该不该现在碰？

该碰，但先用现成模板套，别急着自己写复杂工作流。Actions 本质就是某个事件触发后自动跑一段任务，普通人最用得上的，是挂一个现成模板做定时备份、或让个人网站每次更新自动发布，市场里搜 github actions template 直接抄，很多填几个参数就跑。你现在不用懂它背后的原理，会套模板就能把重复劳动交出去。等真有自动化需求再深学，不熟原理也完全不妨碍先用起来。市场里大量现成工作流，新手改改配置就能用，比如别人写好的每次 push 自动跑测试、网页改动自动部署，照着抄比自己从零写稳得多。真要参与开源，记得先读项目的 CONTRIBUTING 指

南再提 PR，别乱撞。把 Actions 当成会听话的自动打工仔，你下指令它执行，先把最简单的备份、发布跑顺，再谈复杂玩法。可复制模板（直接复制使用）：name: CI on: [push] jobs: test: runs-on: ubuntu-latest steps:

• uses: actions/checkout@v4- run: echo "每次 push 自动跑"## 文件放在：.github/workflows/ci.yml

94. Actions 里的"变量"和"缓存"分别是解决什么痛点的？

变量解决同一段值到处写、改一处要改很多的麻烦：env 管单次工作流内部的值，vars 在 Settings 里管跨多个工作流甚至跨仓库共享的值，一处改全局生效。缓存解决每次跑都重装依赖慢的痛点：把 node_modules 这类依赖按 key 存起来，下次命中就跳过安装，构建时间从几分钟压到几十秒，依赖一变 key 自动换新。两者说到底都是帮你少做重复劳动，属于进阶里最值得懂的两个概念。变量还能跨步骤、跨 job 传值：某步算出的结果写进环境变量文件，后面步骤直接读；上

游 job 定义输出，下游引用即可。缓存也有边界要清楚：单仓库上限 10 GB、超过 7 天没访问会自动清、还按分支隔离，所以别往缓存里塞密钥这类敏感信息。搞懂这两样，你写的自动化才既快又不会悄悄出错。可复制模板（直接复制使用）：

• name: Cache node modules uses: actions/cache@v4 with: path: ~/.npm key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }} restore-keys: | ${{ runner.os }}-npm- # 缓存上限 10GB/仓库，7 天不访问自动清理，按分支隔离

95. 效率党都在用的快捷键与命令面板，哪些最值得第一天就记住？

先记这几组就够：任意页面按 ? 会弹出当前页所有快捷键，这是最省记忆的法子；G 系导航键（G C 跳代码、G I 跳 Issue、G P 跳 PR、G A 跳 Actions）手不离键盘就能穿梭；y 把文件网址固化为永久链接；t 在大仓库里快速找文件；. 一键开 github.dev 网页编辑器直接改。记不住快捷键时，按 Ctrl 或 Command 加 Shift 加 K 打开命令面板，输入就能直达，是记不住时的兜底入口。命令面板里按 # 搜 Issue 和讨论、@ 搜用户和

仓库、/ 搜仓库内文件，已打开时按 > 还能切到命令模式直接运行新建仓库、切主题这类操作，Esc 或再按一次快捷组合就关掉。要是嫌纯字符快捷键容易误触，在账户设置的无障碍选项里可以关掉、只留带修饰键的。

96. 按 "y" 生成永久链接有什么用，分享代码时为什么别发当前网址？

普通文件网址带的是分支名，比如 /blob/main/，分支往后一推进，内容就变了；你今天复制的链接，过阵子别人点开可能已不是原样。按 y 会把网址里的分支名换成具体的 commit ID，生成一条永久不变的链接，对方看到的和你看到的完全一致。它还能对某一行或几行代码生成永久链接，答疑、讨论时引用特别方便。所以凡是想长期引用某段代码，先按 y 再复制，比发当前网址踏实。普通网址之所以会漂，是因为它指向分支最新的头，新提交一进来内容就变；而永久链接把分支名换成了谁都改不了的提交编号。其实 URL 里放分支名、commit 编号或 tag 都行，只要能定位到某个提交就稳定。任意页面按 ? 都能调出全部快捷键，y 只是其中帮你固定引用的一个。

97. 悬停卡片（hover card）能让我不点进去就看清一个链接是啥吗？

能，这是读 GitHub 文档时的省标签页小技巧。在 Docs 里，把焦点放到某篇文章的链接上，按 Alt 或 Option 加向上箭头，就会弹出一张悬停卡片，预览另一篇文章的概要，不用跳转离开当前页。用鼠标悬停也能触发；卡片打开后按 Enter 跟随链接，按 Esc 关闭。它纯键盘也能操作，配合前面说的 ? 快捷键和命令面板一起用，读文档的效率会明显高一些，少开一堆标签页。它在 GitHub 文档站上才生效，文章之间的链接大多支持。除了键盘，用鼠标悬停上去也会弹出卡片，卡片里按 Enter 就跳过去、按 Esc 收起，两条路都通。配合 ? 看快捷键、命令面板直达，三件套一起用，你读一长串文档时就不用开满一屏幕标签页，思路也不断。

98. Copilot CLI 的别名怎么设，敲命令能少打多少字？

给 GitHub Copilot 命令行配两个短别名最实用：ghcs 代替 gh copilot suggest （帮你建议命令），ghce 代替 gh copilot explain（解释命令）。关键是不能手

写普通 alias，必须用官方给的 gh copilot alias 命令生成，它才能替你执行命令；比如 Zsh 用户把那行 eval 加进 ~/.zshrc 即可。配好后 ghcs 执行前默认还会请你确认，不怕它乱动。少打一长串不说，不熟命令的人也敢直接上手问它。设的时候有个坑：必须运行官方那条 eval 命令把别名写进 shell 配置，手写普通 alias 看起来一样、实则 Copilot 没法替你执行命令。配好之后用 gh copilot config 还能改掉默认确认行为；要是不想贡献匿名使用数据，同一处设置里关掉 Optional Usage Analytics 即可。配置一次，长期省事。可复制模板（直接复制使用）：# Zsh / Bash：加到 ~/.zshrc 或 ~/.bashrc echo 'eval "$(gh copilot alias -- zsh)"' >> ~/.zshrc # 之后用两个短别名：ghcs # = gh copilot suggest（建议命令） ghce # = gh copilot explain（解释命令） # 注意：必须用官方 alias 命令生成，不能手写普通 alias

99. 学到什么程度算"够用"了，普通人没必要硬啃哪些深水区？

够用的标准很简单：能靠网页、Fork、PR、README、Pages 把你想办的事办成，就算够用。不用羡慕那些把 Git 命令背得滚瓜烂熟的人，对大多数普通人来说，网页端能传能改、能参与协作，就已经把 GitHub 最值钱的部分用上了。没必要硬啃的有一串：rebase、cherry-pick 这类复杂 Git 命令，自己从头写 Actions 工作流，分支的底层原理，还有 CI 的细碎配置。这些眼下用不上，但等真碰到卡点再查完全来得及。GitHub 的进阶功能多到学不完，硬啃反而容易劝退；把精力放在能立刻用上的部分，剩下的当作随用随查的字典，才是普通人的省力姿势。比起把命令背熟，持续用起来才是正路，教程看十遍，不如自己传十个仓库练出来的手感。

100. GitHub 解决不了什么，哪些事它其实不如专门工具？

它强在代码、版本、协作、开源、展示这一条龙，但有几类活它真不擅长：纯文件同步它不如坚果云、OneDrive 这类网盘顺手；实时讨论它不如群聊快，Discussions 更偏公告和慢聊；跑后端、存数据它做不到，Pages 只能发纯静态网页；复杂项目管理它也比不了 Jira 这种专业工具。所以别神话它，把它当协作与展示的中枢，重活交给专门工具，分工清楚反而用得更爽。顺带提醒一个坑：开源不等于免费乱用，每个项目都带 License，商用

前看清能不能用、怎么署名。把期待摆正，GitHub 在你的工具箱里就该是那个管代码、管协作、管展示的中枢，而不是什么都往里塞。它解决的是软件从写到发到一起改这条链路，链路之外的活，交给更合适的工具反而更高效。