万字长文 ｜超详细的 GitHub 教程，从入门到精通·进阶篇
文章目录
各位推友今天来看 GitHub 进阶篇，学完你就是源码的神！
上一篇讲的是从零到能提 PR。这一篇接着往上走。
Issues 怎么管项目、PR 怎么被 review、冲突怎么解、Actions 怎么定时、命令行工具 gh 怎么用，还有几条约等于"后悔药"的 Git 命令。
上一篇结尾说了一句话：GitHub 是个用得越多、发现越多的地方。这篇讲的就是那些"用得多了才会碰到"的功能。
上一篇有20多万的曝光，感觉大家还是很喜欢github 所以再做一偏进阶。这篇不重复上一篇，没看过的先补这一篇：
本文部分内容以 https://github.com/tw93/Mole 截图为例子讲解
目录
-
一、Issues 管理 —— 从"提问题"变成"管项目"
-
二、PR 进阶 —— Draft、Review、三种合并方式
-
三、第一次解冲突 —— 不慌，按三步走
-
四、Projects —— 一块看板管住所有事
-
五、Release 与 Tag —— 正经地发一个版本
-
六、Actions 进阶 —— 定时、手动、矩阵、缓存
-
七、GitHub CLI —— 命令行里玩 GitHub，快一倍
-
八、安全三件套 —— Dependabot、密钥扫描、代码扫描
-
九、CODEOWNERS 与规则集 —— 把规矩写进文件
-
十、Codespaces —— 网页里的开发机
-
十一、顺手的小功能 —— Discussions、Wiki、Gist、模板仓库
-
十二、Insights 与 Traffic —— 看谁在看你的仓库
-
十三、给仓库加装饰 —— 徽章、Topics、社交预览
-
十四、Git 进阶命令 —— 几条救命的
-
十五、进阶坑集锦 —— 踩过才知道的
-
十六、速查表（进阶）
一、Issues 管理：从提问题变成管项目
上一篇讲了怎么提 Issue、怎么看 Label。这一篇讲怎么拿它管一个项目。
一个仓库的 Issue 区会有几十上百条。想从里面看出"现在该干嘛"，靠四样东西。
| 东西 | 作用 |
|---|---|
| Label（标签） | 分类 |
| Milestone（里程碑） | 一个版本要解决的所有 Issue，打包在一起 |
| Assignee（负责人） | 这件事谁来做 |
| Pin（置顶） | 把最重要的几条钉在顶部 |
Milestone 是最被低估的一个。 建一个 v1.0 的 milestone，把这一版要做的 Issue 全挂上去。进度条就在 milestone 页面上——做完几条、还剩几条，一眼看清。
Pin 用来压住最重要的那条。 长期置顶一条"新手请先读这个"或者"已知问题汇总"，能省下大量重复提问。
Issue 模板：让提问的人把话说全
在仓库里建 .github/ISSUE_TEMPLATE/bug_report.md，以后新建 Issue 会自动套上这个模板。
一个最小可用的：
---
name: Bug 反馈
about: 报告一个可以复现的问题
---
### 问题是什么
点登录按钮没反应。
### 怎么复现
1. 打开 /login
2. 输入任意邮箱密码
3. 点登录
### 期望的结果
进入首页。
### 环境
Chrome 120 / macOS 14
三段为什么值钱。 维护者最想知道的就是三件事：复现路径、期望结果、运行环境。写全了当天就能定位，不写就得来回问三天。
模板别塞十几个字段。填的人一烦，直接关掉不反馈了。
关键词自动关闭 Issue
PR 描述里写一句 Closes #12，这个 PR 被合并时，第 12 号 Issue 会自动关掉。
同一组关键词还有 Fixes、Resolves，挑一个用就行。
这条省下的是手工操作。 一个 PR 修三个 Issue，就写三行：
Closes #12
Closes #15
Fixes #31
二、PR 进阶：Draft、Review 和三种合并
上一篇走完了提 PR 的全流程。这一篇讲 PR 提出来之后会发生什么。
Draft PR：还没写完就提
在 PR 创建页点开那个绿色按钮旁的下拉框，选 Create draft pull request。
提出来是灰色标记，意思是"别急着看，我还在改"。这个状态下别人合并不了。
什么时候用： 想法还不成熟，又想让维护者早点看到方向对不对。比闷头写完再提好——方向错了，早发现早省事。
改完了，点 Ready for review 转正。
Review 的三种动作
别人打开你的 PR，在 Files changed 页面上能做三件事：
| 动作 | 意思 |
|---|---|
| Comment | 只留评论，不给结论 |
| Approve | 同意合并 |
| Request changes | 要求修改，不通过 |
Request changes 是硬拦截。有它挡着，PR 合不进去，除非改了，或者有权限的人绕过。
被 Request changes 不是坏事。 那是维护者在告诉你他真正在乎什么。认真读完这几条，比读十篇代码规范有用。
三种合并方式，差别很大
PR 页面底部那个合并按钮，旁边有个下拉框，三种选法：
| 方式 | 结果 | 什么时候用 |
|---|---|---|
| Merge commit | 保留全部分支历史，多一条合并节点 | 想保留完整过程 |
| Squash and merge | 把整个 PR 压成一条提交 | 小改动、修 bug。默认推荐 |
| Rebase and merge | 把每条提交原样接到主干上，不留合并节点 | 提交干净、想要线性历史 |
新手默认选 Squash。 一个 PR 里可能有十次"改错了重来"的提交，压成一条，主干历史才干净。
Merge commit 会留一堆碎提交。Rebase 会重写提交的哈希——已经推送、别人在用的分支，别用 Rebase。
PR 也能挂标签
和 Issue 一样，PR 也能挂 label、milestone、assignee。
多人项目里，这套标记是给 PR 分流的：待 review、等作者回复、就差合并了。不开标签，一堆 PR 躺在那儿，谁也不知道哪个卡在谁手上。
三、第一次解冲突
一句话：两边改到了同一行，Git 不知道该听谁的，让你自己决定。
冲突不长在编辑器里，长在文件里。打开那个文件，会看到这样的东西：
<<<<<<< HEAD
按钮颜色用蓝色
=======
按钮颜色用绿色
>>>>>>> feature/new-button
<<<<<<< 和 ======= 之间是当前分支的版本，======= 和 >>>>>>> 之间是另一个分支的版本。
处理办法就三步：
-
删掉那三行标记（<<< === >>>）
-
留下你要的那段，或者两段合成一段
-
保存，git add 那个文件，继续 git commit
网页上也能解。PR 页面看到 This branch has conflicts that must be resolved，点 Resolve conflicts，直接在网页编辑器里改，改完点 Mark as resolved。
两个提醒：
-
冲突标记一定要删干净。漏一个，代码直接语法错误。
-
解完先在本地跑一遍再推。冲突解错是能跑起来的——语法对，逻辑不一定对。
四、Projects：一块看板管住所有事
一句话：Projects 是一个自动汇总 Issue 和 PR 的看板。
仓库顶部有一排标签：Code、Issues、Pull requests、Actions，再往右就是 Projects。
点进去 New project，可以选表格视图、看板视图、路线图视图。
它的意义是：Issue 是散落的，看板是排好的。
最小用法，四列就够：
| 列 | 放什么 |
|---|---|
| 待办 | 新提的、还没排期的 |
| 这周做 | 排进当前周期的 |
| 进行中 | 正在动的 |
| 已完成 | 关掉的 |
把 Issue 拖进对应列，状态会同步回 Issue 本身——在看板上标"已完成"，那条 Issue 也就关了。
自动化的用法： 设一条规则，"Issue 一被创建，自动加进待办列"。这样新问题再也不会沉底。
一个人做项目，看板有点像杀鸡用牛刀。但仓库一旦有第二个人的问题要处理，它立刻值钱。
五、Release 与 Tag：正经发一个版本
一句话：Tag 是给某次提交贴一个版本号，Release 是围绕这个版本号写的一页说明。
Tag 可以只当书签用：
git tag v1.0.0 #给当前提交打一个 tag
git push origin v1.0.0 #tag 要单独推，不跟着 push 走
版本号有惯例，三位数 v1.2.3：
| 位数 | 什么时候加 |
|---|---|
| 第一位（1） | 有大改动、不兼容老版本 |
| 第二位（2） | 加了新功能，兼容老版本 |
| 第三位（3） | 只修 bug |
在仓库的 Releases 页面点 Draft a new release，选一个 tag，写标题和说明，就成了一次正式发布。
说明不用从零写。 页面上有个 Generate release notes，GitHub 会把从上个 tag 到现在之间的 PR 自动汇总成一份草稿。
发完，Releases 页面就成了一条时间线。别人一眼能看出这个项目还在不在维护。
六、Actions 进阶：定时、手动、矩阵、缓存
上一篇讲了 Actions 的最小例子和免费额度。这篇讲四个真正提升效率的用法，外加两个调度细节。
定时跑：cron
on:
schedule:
- cron: '0 9 * * *' #每天 UTC 9 点，也就是北京时间下午 5 点
timezone: "Asia/Shanghai" # 加了这行才是北京时间
两个坑：
-
cron 用的是 UTC 时间，不是北京时间。要减 8 小时。默认按 UTC，加一行 timezone: "Asia/Shanghai" 就能直接写北京时间。
-
定时任务不保证准点。GitHub 负载高的时候会排队，晚十几分钟是正常的。
定时任务的典型用途：每天抓一次数据、每天备份一次、每周清理一次过期文件。
手动触发：workflow_dispatch
on:
workflow_dispatch: #在 Actions 页面出现一个 Run workflow 按钮
加了这段，这个 workflow 在 Actions 标签页会多一个按钮，点一下就手动跑一次。
调试的时候特别好用。 不用为了测一次而专门推一次代码。
一次跑多个版本：matrix
同一个测试，想在多个系统、多个语言版本上各跑一遍，不用写多份：
strategy:
matrix:
os: [ubuntu-latest, macos-latest]
node: ['18', '20']
它会自动组合出四份任务（2 个系统 × 2 个版本），并行跑。
注意：macOS 是 10 倍计费。 矩阵里带上 macOS，消耗直接翻十倍，上一篇章里算过这笔账。
缓存依赖：cache
每次跑都重新 npm install，慢得让人不想推代码。加一段缓存：
- uses: actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}
key 里带上锁文件的哈希，依赖没变就命中缓存，变了自动重建。第二次以后的运行能快一大截。
两个调度细节：依赖和并发
任务之间可以有先后。needs 声明"我等谁跑完再跑"：
jobs:
test:
runs-on: ubuntu-latest
steps: ...
deploy:
needs: test #test 过了才跑 deploy
runs-on: ubuntu-latest
steps: ...
这是"测试不过不许部署"的最小实现。
concurrency 管的是"同一时间只跑一个"：
concurrency:
group: deploy
cancel-in-progress: true #新的进来，老的自动取消
部署类任务一定加这个。 不然两次推送撞在一起，线上会同时跑两份部署。
用现成的：Marketplace
别自己从零写 action。GitHub 的 Marketplace 里有几万个现成的，搜关键词，复制两行就能用。
常用的几个：actions/checkout（拉代码）、actions/setup-node（装 Node）、actions/cache（缓存）、actions/upload-artifact（存构建产物）。
七、GitHub CLI：命令行里玩 GitHub
一句话：gh 是 GitHub 官方的命令行工具，把网页上点来点去的操作变成一行命令。
安装：
brew install gh #macOS
gh auth login #登录，会引导走一遍网页授权
为什么要用它： 提 PR 这件事，网页上要点五次。命令行一行：
gh pr create --title "修正死链" --body "Closes #12" #创建 PR
几条真正高频的：
gh repo create 项目名 --public #建仓库，不用先上网页
gh repo clone 用户/仓库 #克隆
gh issue list #看当前仓库所有 Issue
gh pr list #看所有 PR
gh pr checkout 123 #把第 123 号 PR 拉到本地
gh pr status #我提的 PR 现在什么状态
gh run list #看最近的 Actions 运行
gh run watch #实时盯一次 Actions 跑
gh release create v1.0.0 #直接发一个 release
gh gist create 文件 #把文件传成 Gist
gh run watch 是最省心的一条。 推完代码，不用切浏览器、翻 Actions 页面、找那次运行——在终端里盯着就行。
八、安全三件套：让仓库自己报警
一句话：这三样基本都免费，开一次，以后自动盯着。
Dependabot：依赖有漏洞会通知你
项目里用的第三方库，作者发了补丁，你不会知道。Dependabot 会。
在仓库的 Settings → Code security 里打开 Dependabot alerts 和 Dependabot security updates。
开完之后：
-
有漏洞的依赖会出一条警报
-
还能自动提 PR 帮你升级
它免费对所有仓库开放。开了不亏。
Secret scanning：密钥提交上去会报警
.env、ghp_ 开头的 token、sk- 开头的 key——一旦进了提交，GitHub 会扫到并提醒。
公开仓库默认开启。 它拦的正是上一篇那个最严重的坑：密钥提交。
但记住，它是事后报警，不是事前拦截。真提交上去了，该作废的还是要作废。
Code scanning：代码本身有漏洞也能扫
GitHub 自己的扫描引擎叫 CodeQL。它分析的是代码逻辑，能查出注入、越权这类问题。
公开仓库免费，私有仓库要看套餐。个人公开项目直接开就行。
加上两步验证，账号这一层才算齐。 2FA 和恢复码的事上一篇讲过，恢复码只显示一次，必须存下来。
九、CODEOWNERS 与规则集：把规矩写进文件
一句话：CODEOWNERS 规定"改哪些文件得谁点头"，规则集规定"哪些操作不许做"。
CODEOWNERS：自动指派 review
在仓库里建一个 .github/CODEOWNERS 文件，一行一条规则：
# 改文档得文档负责人点头
/docs/ @文档负责人
# 改部署配置得运维点头
/deploy/ @运维负责人
# 兜底：没人认领的改动，默认归我
* @你的用户名
写完，谁改到这些路径，GitHub 自动把对应的人加进 review 名单。
它和分支保护配合才有强制力。 光写文件，只是"建议谁来看"；开了分支保护里的 Require review from Code Owners，才是"必须他们点头才能合"。
规则集：补一条最容易漏的
上一篇的分支保护和规则集讲过了，这里只补一条最容易漏的。
给 main 加规则时，把 Require status checks to pass 勾上，再选上你的 Actions 检查项。
意思是：测试没过，PR 根本合不进去。 这比靠人自觉靠谱得多。
十、Codespaces：网页里的开发机
一句话：一台开在浏览器里的电脑，里面装好了你的项目。
在仓库页面点绿色的 Code 按钮，切到 Codespaces 标签，点 Create codespace on main。
等一两分钟，会打开一个网页版的 VS Code。代码已经克隆好了，终端、插件都在。
什么时候用：
-
换了台电脑，没装环境，想立刻改两行
-
给别人演示项目，不想讲怎么配环境
-
用 iPad 这类不方便装环境的设备
最大的坑是存储计费。 停掉只停止算力计费，存储照样算。
不用的 Codespace 一定要删掉，不是停掉。免费额度是每月 120 核心小时 + 15 GB 存储，超了要付费。
十一、顺手的小功能：Discussions、Wiki、Gist、模板仓库
四个不常用、但用起来很舒服的功能。
Discussions：给项目开个论坛
在 Settings → General → Features 里勾上 Discussions。
它和 Issue 的分工：
| Issue | Discussions | |
|---|---|---|
| 用途 | 能关闭的具体任务 | 开放式的交流和问答 |
| 有没有"完成"一说 | 有 | 没有 |
Issue 关得掉，Discussions 关不掉。 所以"这个功能怎么做"用 Issue，"大家怎么看这个功能"用 Discussions。
Wiki：项目自己的文档站
仓库顶部的 Wiki 标签，是一个自带版本管理的小文档站。
适合放长文档：安装指南、架构说明、常见问题。比塞在 README 里强——README 太长没人读，Wiki 可以一页一个主题。
Gist：代码片段
访问 gist.github.com，可以贴一小段代码，单独分享。
它有自己的版本历史，还能嵌到博客里。 分享一段配置给别人，比截图强——截图不能复制。
模板仓库：一键生成新项目
把自己的某个仓库设成模板：Settings → 勾 Template repository。
之后别人（包括你自己）在仓库页面能看到一个绿色的 Use this template 按钮。点一下，复制出一份全新的项目，历史是干净的。
自己的项目骨架最适合这么做。 下次开新项目，不用再从头配一遍。
十二、Insights 与 Traffic：看谁在看你的仓库
仓库顶部有个 Insights 标签。对做站、做开源的人有用。
点进去 Traffic，能看到：
| 指标 | 意思 |
|---|---|
| Views | 有多少人看了这个仓库 |
| Clones | 被克隆了多少次 |
| Referring sites | 从哪些网站跳过来的 |
两个实用用法：
-
看来源。 如果一堆流量从某个论坛来，说明那篇帖子带来了关注，可以去那里多露面。
-
看趋势。 发了篇文章之后克隆量涨了，说明文章真的把人带过来了。
Traffic 只保留 14 天。 想看长期趋势，得自己定期导出。
Insights 里的 Contributors 能看到谁贡献了多少提交，Community 会给你的仓库打分——有没有 LICENSE、README、贡献指南，一目了然。
十三、给仓库加装饰：徽章、Topics、社交预览
一句话：别人搜到你的仓库之前，第一眼看到的是 Topics 和那张预览图。
Topics：让仓库能被搜到
在仓库页面右上角点 About 旁边那个齿轮，能加 Topics。填几个关键词，比如 claude-code、obsidian、ai-agent。
加了之后，别人点 topic 就能逛到你的仓库。这是最省事的曝光。
徽章：README 顶上那排小图标
shields.io 这个站，把一行 markdown 贴进 README，就生成一个徽章。
别挂一堆。 星数、许可、最近提交时间，三个就够。挂二十个反而显得吵。
社交预览图
在 Settings 里传一张 Social preview，别人分享你的仓库链接时，卡片上显示的就是这张图。
默认是一张灰底文字图。 换成自己做的封面，点击率完全不一样。
十四、Git 进阶命令：几条救命的
上一篇的速查表是日常三行。这一篇是几条例外情况的。
git reflog：误删的救命稻草
一句话：reflog 记录了你在这个仓库里做过的每一次操作，连"被删掉的提交"都在。
什么时候用：git reset --hard 退多了、分支被误删了、rebase 搞砸了。
git reflog #看最近的操作记录
git reset --hard HEAD@{3} #回到三次操作之前的状态
这是最接近"撤销一切"的一条命令。 东西没丢，只是 HEAD 指错了地方。
git commit --amend：把刚才那次提交改一改
提交完发现写错了一个字，不用再提一次：
git commit --amend #把当前改动并进上一次提交，顺便改说明
注意：已经推送过的提交，别用 amend。 它会改掉提交的哈希，和远端对不上，只能强推，又会覆盖别人。
revert 和 reset 的区别
两个都是"撤销"，但完全不同：
| revert | reset | |
|---|---|---|
| 做什么 | 新建一条"反向提交" | 把历史指针往回挪 |
| 历史 | 保留，多一条 | 被抹掉 |
| 已推送的分支 | 安全，推荐 | 危险，要强推 |
| 用途 | 撤销公共分支上的提交 | 清理本地没推的东西 |
记法：revert 是"记一笔撤销记录"，reset 是"当没发生过"。 已经推出去的，永远用 revert。
git cherry-pick：只把某一次提交搬过来
想把别的分支上某一个提交拿到当前分支，不用整个合并：
git cherry-pick <提交的哈希>
典型场景： 在 dev 上修了个 bug，想单独把这个修复弄到 main 上，而 dev 上别的东西还不想要。
十五、进阶坑集锦
七个坑，踩过才知道。
坑一：向错误的仓库提 PR。 从自己的 fork 建分支，却把 PR 提回了自己的 fork，而不是原项目。提完半天没人理，回头才发现地点错了。提 PR 时看清楚那个下拉框里的 base repository。
坑二：给公开分支做 rebase。 rebase 会重写提交哈希。别人的工作基于旧的哈希，一 rebase，他们那边全乱。没推送的分支随便 rebase，推出去的别碰。
坑三：强推覆盖别人的提交。 git push --force 是危险的，--force-with-lease 安全一些——它会先检查远端的提交有没有变，变了就拒绝。养成用 --force-with-lease 的习惯。
坑四：Dependabot 的 PR 堆一桌子。 打开自动升级之后，一周能攒出二十个 PR。别全合，只处理标了安全警报的那些，其余设一个每周合并一次的节奏。
坑五：Codespaces 忘了删。 停掉不等于删掉。存储按小时计费，一个忘掉的 Codespace 能安静地吃掉额度。
坑六：cron 写成北京时间。 '0 9 * * *' 是 UTC 9 点，不是北京 9 点。要北京早上 9 点跑，得写 '0 1 * * *'。 默认按 UTC，加一行 timezone: "Asia/Shanghai" 就能直接写北京时间。
坑七：规则集没选 Active。 建 branch ruleset 时，Enforcement status 默认可能是 Disabled。看着配好了，其实一点没生效。建完回来确认那一栏是 Active。
十六、速查表（进阶）
# Tag 与发布
git tag v1.0.0 #给当前提交打 tag
git push origin v1.0.0 #tag 要单独推
# 救命
git reflog #看所有操作历史
git reset --hard HEAD@{3} #回到三步之前
git commit --amend #修改上一次提交（未推送的才行）
# 撤销的正确姿势
git revert <哈希> #撤销已推送的提交（安全）
# 挑选提交
git cherry-pick <哈希> #只搬一个提交过来
# 强推（尽量用后者）
git push --force #危险
git push --force-with-lease #安全一些
# GitHub CLI
gh auth login #登录
gh pr create #创建 PR
gh pr checkout 123 #把 123 号 PR 拉到本地
gh run watch #实时盯 Actions
gh issue list #列 Issue
一条总原则：已经推送到公共分支的东西，只做"加一笔"的操作（revert），不做"抹历史"的操作（reset、rebase、force push）。
最后
这一篇讲的功能，大部分不是每天都用。它们的价值在于知道它们存在——真到了那一天，你知道该搜哪个词。
三条记下来就够：
-
Issues 和 Projects 是管"接下来做什么"的。 一个人可以不用，两个人就离不开。
-
Actions 一旦定时跑起来，就是一个不要钱的机器人。 cron 记得换算时区。
-
Git 里没有真正的"删掉"。 reflog 基本能找回一切，前提是别把 .git 删了。
上一篇结尾说过一句话：GitHub 是个用得越多、发现越多的地方。这篇里的每一条，都是那句话的注脚。
往期优秀文章：
Codex 自媒体运营 Skill 大全｜20 个装完，一个人顶一个团队
我是想风 @xaiwind，一个关注出海与 AI、AIGC 的创作者。
本文基于AI辅助与个人实践融合创作，如果文章对你有帮助，欢迎点赞、收藏、关注，
本人文章持续修正，欢迎联系或者评论区见，每天进步一点，我们终会到达目的地！
