东西	作用
Label（标签）	分类
Milestone（里程碑）	一个版本要解决的所有 Issue，打包在一起
Assignee（负责人）	这件事谁来做
Pin（置顶）	把最重要的几条钉在顶部

Milestone 是最被低估的一个。 建一个 v1.0 的 milestone，把这一版要做的 Issue 全挂上去。进度条就在 milestone 页面上——做完几条、还剩几条，一眼看清。

Pin 用来压住最重要的那条。 长期置顶一条"新手请先读这个"或者"已知问题汇总"，能省下大量重复提问。

Issue 模板：让提问的人把话说全

在仓库里建 .github/ISSUE_TEMPLATE/bug_report.md，以后新建 Issue 会自动套上这个模板。

一个最小可用的：

三段为什么值钱。 维护者最想知道的就是三件事：复现路径、期望结果、运行环境。写全了当天就能定位，不写就得来回问三天。

模板别塞十几个字段。填的人一烦，直接关掉不反馈了。

关键词自动关闭 Issue

PR 描述里写一句 Closes #12，这个 PR 被合并时，第 12 号 Issue 会自动关掉。

同一组关键词还有 Fixes、Resolves，挑一个用就行。

这条省下的是手工操作。 一个 PR 修三个 Issue，就写三行：

二、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 不知道该听谁的，让你自己决定。

冲突不长在编辑器里，长在文件里。打开那个文件，会看到这样的东西：

<<<<<<< 和 ======= 之间是当前分支的版本，======= 和 >>>>>>> 之间是另一个分支的版本。

处理办法就三步：

删掉那三行标记（<<< === >>>）

留下你要的那段，或者两段合成一段

保存，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 可以只当书签用：

版本号有惯例，三位数 v1.2.3：

位数	什么时候加
第一位（1）	有大改动、不兼容老版本
第二位（2）	加了新功能，兼容老版本
第三位（3）	只修 bug

在仓库的 Releases 页面点 Draft a new release，选一个 tag，写标题和说明，就成了一次正式发布。

说明不用从零写。 页面上有个 Generate release notes，GitHub 会把从上个 tag 到现在之间的 PR 自动汇总成一份草稿。

发完，Releases 页面就成了一条时间线。别人一眼能看出这个项目还在不在维护。

六、Actions 进阶：定时、手动、矩阵、缓存

上一篇讲了 Actions 的最小例子和免费额度。这篇讲四个真正提升效率的用法，外加两个调度细节。

定时跑：cron

两个坑：

cron 用的是 UTC 时间，不是北京时间。要减 8 小时。

定时任务不保证准点。GitHub 负载高的时候会排队，晚十几分钟是正常的。

定时任务的典型用途：每天抓一次数据、每天备份一次、每周清理一次过期文件。

手动触发：workflow_dispatch

加了这段，这个 workflow 在 Actions 标签页会多一个按钮，点一下就手动跑一次。

调试的时候特别好用。 不用为了测一次而专门推一次代码。

一次跑多个版本：matrix

同一个测试，想在多个系统、多个语言版本上各跑一遍，不用写多份：

它会自动组合出四份任务（2 个系统 × 2 个版本），并行跑。

注意：macOS 是 10 倍计费。 矩阵里带上 macOS，消耗直接翻十倍，上一篇章里算过这笔账。

缓存依赖：cache

每次跑都重新 npm install，慢得让人不想推代码。加一段缓存：

key 里带上锁文件的哈希，依赖没变就命中缓存，变了自动重建。第二次以后的运行能快一大截。

两个调度细节：依赖和并发

任务之间可以有先后。needs 声明"我等谁跑完再跑"：

这是"测试不过不许部署"的最小实现。

concurrency 管的是"同一时间只跑一个"：

部署类任务一定加这个。 不然两次推送撞在一起，线上会同时跑两份部署。

用现成的：Marketplace

别自己从零写 action。GitHub 的 Marketplace 里有几万个现成的，搜关键词，复制两行就能用。

常用的几个：actions/checkout（拉代码）、actions/setup-node（装 Node）、actions/cache（缓存）、actions/upload-artifact（存构建产物）。

七、GitHub CLI：命令行里玩 GitHub

一句话：gh 是 GitHub 官方的命令行工具，把网页上点来点去的操作变成一行命令。

装：

为什么要用它： 提 PR 这件事，网页上要点五次。命令行一行：

几条真正高频的：

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 文件，一行一条规则：

写完，谁改到这些路径，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 搞砸了。

这是最接近"撤销一切"的一条命令。 东西没丢，只是 HEAD 指错了地方。

git commit --amend：把刚才那次提交改一改

提交完发现写错了一个字，不用再提一次：

注意：已经推送过的提交，别用 amend。 它会改掉提交的哈希，和远端对不上，只能强推，又会覆盖别人。

revert 和 reset 的区别

两个都是"撤销"，但完全不同：

ㅤ	revert	reset
做什么	新建一条"反向提交"	把历史指针往回挪
历史	保留，多一条	被抹掉
已推送的分支	安全，推荐	危险，要强推
用途	撤销公共分支上的提交	清理本地没推的东西

记法：revert 是"记一笔撤销记录"，reset 是"当没发生过"。 已经推出去的，永远用 revert。

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 * * *'。

坑七：规则集没选 Active。 建 branch ruleset 时，Enforcement status 默认可能是 Disabled。看着配好了，其实一点没生效。建完回来确认那一栏是 Active。

十六、速查表（进阶）

一条总原则：已经推送到公共分支的东西，只做"加一笔"的操作（revert），不做"抹历史"的操作（reset、rebase、force push）。

最后

这一篇讲的功能，大部分不是每天都用。它们的价值在于知道它们存在——真到了那一天，你知道该搜哪个词。

三条记下来就够：

Issues 和 Projects 是管"接下来做什么"的。 一个人可以不用，两个人就离不开。

Actions 一旦定时跑起来，就是一个不要钱的机器人。 cron 记得换算时区。

Git 里没有真正的"删掉"。 reflog 基本能找回一切，前提是别把 .git 删了。

上一篇结尾说过一句话：GitHub 是个用得越多、发现越多的地方。这篇里的每一条，都是那句话的注脚。

篇幅有限，还有没讲到的——Issue 表单、Actions 的其他玩法，以后单独开篇。

我是想风@xaiwind，一个关注出海与 AI、AIGC 的创作者。

本文基于AI辅助与个人实践融合创作，如果文章对你有帮助，欢迎点赞、收藏、关注，

本人文章包售后欢迎联系或者评论区见，每天进步一点，我们终会到达目的地！

超详细 Claude Code 终端教程，从入门到精通（国产模型版）

万字长文｜超详细的 GitHub 教程，从入门到精通

Last update: 2026-10-20

🎉跨境电商技术支持团队🎉

--感谢您的认可与信赖--

Shopify官网注册-获取本人免费使用支持

👏有需要欢迎资讯👏学习、交流亦可

🛠️万字长文 ｜超详细的 GitHub 教程，从入门到精通·进阶篇

目录

一、Issues 管理：从提问题变成管项目