GitHub 演示教程：从零跑通协作全流程
10 分钟带你完成一次完整的 GitHub 协作闭环：仓库创建、分支与 PR、Issue 追踪、Actions 自动测试，覆盖 GitHub Flow、Pull Request 审查、Issues 任务管理以及 GitHub Actions 自动化 CI/CD。
视频讲解
GitHub 演示教程：从零跑通协作全流程
10 分钟带你完成一次完整的 GitHub 协作闭环：仓库创建 → 分支与 PR → Issue 追踪 → Actions 自动测试。
开场 Hook（0:00–0:15）
GitHub 绝不仅仅是一个"代码网盘"。它是建在 Git 之上的协作操作系统：分支策略、Pull Request 代码审查、Issues 任务追踪、Actions 自动化 CI/CD——这四件套组合起来，决定了一个团队到底能不能高效交付代码，也是判断工程师协作素养的重要标志。今天这 10 分钟，我们用一个 Node.js 小项目，把这套工作流完整跑一遍。你会看到，从创建仓库到 PR 自动关闭 Issue，每一步都有它的道理。学完这节课，你就能在自己的项目里直接落地这套流程，并理解每一个环节背后"为什么这样做"的设计动机。
第一章：认识 GitHub（0:15–2:15）
本章目标
理解 GitHub 的本质：Git 仓库的云端托管 + 协作抽象层。掌握 Repository、Fork、Pull Request 三个核心概念，看清本地 Git 和远程 GitHub 是怎么配合工作的。
为什么需要 GitHub
你和同事合作一个项目，U 盘传来传去、微信发压缩包——版本乱了、冲突了、不知道谁改了什么。GitHub 解决的不只是"代码存储"，而是"谁改了什么、为什么改、怎么合进去"的全流程可追溯问题。它不替代 Git，而是在 Git 之上加了一层协作：Pull Request 让审查成为流程的一部分，Issues 让任务可追踪，Actions 让自动化零成本跑起来。今天这一章，我们先把最基础的"仓库怎么建、怎么推"过一遍。
Demo 1.1：创建第一个远程仓库
Screen
打开浏览器，登录 github.com，点击右上角 "+" → "New repository"。填写仓库名 hello-github-demo，选 "Public"（公开仓库，演示用），勾选 "Add a README file"，点击 "Create repository"。页面跳转到新建的仓库主页。
Command
# 在本地初始化项目并推送到 GitHub
mkdir hello-github-demo
cd hello-github-demo
echo "# Hello GitHub Demo" > README.md
git init
git add README.md
git commit -m "Initial commit"
git remote add origin https://github.com/<your-username>/hello-github-demo.git
git push -u origin main
Output
Initialized empty Git repository in /Users/demo/hello-github-demo/.git/
[main (root-commit) 3f2a1b9] Initial commit
1 file changed, 1 insertion(+)
create mode 100644 README.md
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 226 bytes | 226.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/<your-username>/hello-github-demo.git
* [new branch] main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.
Narration
一个仓库就两件事：本地有 .git 目录记录完整历史，GitHub 上有对应的云端副本。git init 在本地建仓库，git add 把文件加入暂存区，git commit 拍快照写入历史。git remote add origin <URL> 把两者绑定起来——origin 是远程的默认别名，你可以叫别的名字，但大家都用 origin，这是约定。git push -u origin main 是首次推送，-u 是 --set-upstream 的缩写，告诉 Git"以后这个分支就推到这里，不用每次都写完整路径"。注意 <your-username> 占位符要替换成你自己的 GitHub 用户名。推完之后刷新 GitHub 页面，你会看到 README.md 已经显示出来了——这就是本地和云端实时同步的样子。
Demo 1.2：克隆仓库到本地
Screen
浏览器切到刚才创建的仓库页面，点击绿色 "Code" 按钮，弹出下拉框显示 HTTPS URL，旁边有个复制图标。点击复制。终端切到桌面目录，方便观察。
Command
cd ~/Desktop
git clone https://github.com/<your-username>/hello-github-demo.git
cd hello-github-demo
ls -la
Output
Cloning into 'hello-github-demo'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
total 16
drwxr-xr-x 5 demo staff 160 Jul 6 10:30 .
drwxr-xr-x 4 demo staff 128 Jul 6 10:30 ..
drwxr-xr-x 12 demo staff 384 Jul 6 10:30 .git
-rw-r--r-- 1 demo staff 23 Jul 6 10:30 README.md
Narration
git clone 干了两件事：把仓库完整历史下载到本地，自动建好 origin 远程指针。这就是协作者加入项目的标准姿势——拿到 URL，clone 下来就能开干。注意 ls -la 里看到的 .git 目录，这是 Git 的"数据库"，所有提交、分支、远程配置都存在这里，千万别手动改它。README.md 也能看到，说明 clone 完整恢复了工作区。这就是为什么 GitHub 适合协作：任何人任何时候都能从同一个起点开始工作。
本章小结
- 关键收获：GitHub 增强 Git 而非替代 Git，本地 Git + 云端仓库 + PR 协作层构成完整闭环
- 使用场景：个人项目备份、团队协作仓库、开源项目发布
- 过渡：仓库有了，代码也推上去了，但一个人开发不叫协作。下一章我们演示 GitHub 的灵魂——Pull Request 工作流
第二章：GitHub Flow 协作工作流（2:15–4:45）
本章目标
掌握 GitHub Flow：feature 分支 → push → Pull Request → Review → Merge 的 6 步法。这是从"个人开发"切换到"团队协作"的关键流程。
为什么需要流程
5 个人同时改 main 分支，5 辆车撞进同一个路口——轻则代码冲突，重则线上事故。GitHub Flow 用最简规则让团队有序：main 永远保持可部署状态，功能在独立分支开发，合并前必须通过 PR 审查。这套流程门槛极低——记住 6 步就行——但规模化能力极强，从 3 人创业公司到 10 万员工大厂都在用。
Demo 2.1：创建 feature 分支并推送
Screen
终端当前在 hello-github-demo 目录，编辑器准备打开 app.js（如果文件不存在就先创建）。状态栏显示当前分支是 main。
Command
git checkout -b feature/greeting
echo "console.log('Hello from GitHub Actions!')" > app.js
git add app.js
git commit -m "Add greeting script"
git push -u origin feature/greeting
Output
Switched to a new branch 'feature/greeting'
[feature/greeting 8a3f2c1] Add greeting script
1 file changed, 1 insertion(+)
create mode 100644 app.js
Enumerating objects: 4, done.
* [new branch] feature/greeting -> feature/greeting
Branch 'feature/greeting' set up to track remote branch 'feature/greeting' from 'origin'.
Narration
git checkout -b feature/greeting 等于"创建并切换分支"，一步到位。分支命名有约定：feature/ 加动词加对象（feature/login-page、feature/greeting），fix/ 表示修 bug（fix/navbar-bug），docs/ 表示改文档（docs/api-guide）。好的命名让 PR 列表按类型分组，可读性强很多。提交后 git push -u origin feature/greeting 把分支推到 GitHub。-u 仍然是 set upstream，推送之后，本地和远程就建立了绑定，后续直接 git push 就行，不用再写完整路径。
Demo 2.2：发起 Pull Request
Screen
刷新 GitHub 仓库页面，黄色提示条出现："feature/greeting had recent pushes — Compare & pull request"。点击这个按钮，跳转到 PR 创建页面。
Command
# 假设在 PR 页面填写：
# Title: Add greeting script
# Description: 添加一段输出欢迎信息的脚本，为后续 CI 测试做准备
# Base: main ← Compare: feature/greeting
# 然后点击 "Create pull request"
echo "PR created at: https://github.com/<your-username>/hello-github-demo/pull/1"
Output
Open
feature/greeting wants to merge 1 commit into main
• Add greeting script · 8a3f2c1
demo opened this pull request just now
Narration
PR 不是 Git 原生概念，是 GitHub 在 Git 之上发明的协作抽象——它的本质是"我改好了，请审一下再合"。注意三个写法：标题用动词开头写做了什么（"Add greeting script"），描述写为什么这么做、怎么测试。好的 PR 描述能省 Reviewer 半小时，避免反复追问。Base 分支是目标（这里是 main），Compare 分支是源头（feature/greeting），GitHub 会自动算出两个分支的差异行数，提前展示给你。
Demo 2.3：审查并合并 PR
Screen
PR 页面往下拉，切到 "Files changed" 标签，每一行加号和减号高亮显示。Reviewer 在某一行点击行号旁边的 "+"，添加评论："能不能把字符串提到变量里？"。
Command
# 模拟 PR 作者回应评论并更新代码
git checkout feature/greeting
echo "const message = 'Hello from GitHub Actions!'; console.log(message);" > app.js
git add app.js
git commit -m "Use variable for script clarity"
git push origin feature/greeting
# 回到网页 Reviewer 通过后，点击 "Merge pull request" → "Squash and Merge" → "Confirm squash and merge"
Output
feature/greeting had recent pushes
• Use variable for script clarity · c4d8e2f
✓ Merged
Squash merge: 2 commits collapsed into 1
• demo merged 2 commits into main just now
• Squash and merge
Narration
PR 自动跟着新 commit 更新 diff，这是 GitHub 实时追踪的妙处——不用重新发起 PR。Squash and Merge 把分支里所有 commit 压缩成一个，main 历史清爽；Merge Commit 保留完整分支历史（看得见 feature 怎么合并的），适合审计要求高的项目；Rebase and Merge 产生线性历史，适合追求极简的项目。小团队推荐 Squash——一个 PR 一个 commit，主干历史最干净。合并后 GitHub 提示你可以删除远程分支——保留也行，但删除能保持仓库整洁。
本章小结
- 关键收获：feature 分支开发 → push → PR → Review → Squash Merge 是 GitHub Flow 完整闭环
- 使用场景：几乎所有现代团队，从 3 人创业公司到 10 万员工大厂
- 过渡：流程跑通了，那项目里那么多 bug 和需求怎么追踪？下一章我们用 Issues 把它们管起来
第三章：Issues 与项目管理（4:45–6:45）
本章目标
学会用 Issues 跟踪工作、Labels 分类、Milestones 规划迭代。理解 PR 怎么通过关键字自动关闭 Issue，把代码交付和任务追踪绑定起来。
为什么需要 Issues
脑子里记着 3 个 bug、5 个需求、2 个优化项，一周后忘了一半，优先级全乱了。Issue 是一个可讨论、可追踪、可分配、可关联 PR 的任务实体——它不是备忘录，而是有状态机的活任务：可以打标签、分配到人、加入迭代、PR 合并时自动关闭。
Demo 3.1：创建 Issue 模板
Screen
终端，仓库根目录。准备在 .github/ISSUE_TEMPLATE/ 下创建 bug 报告模板。
Command
mkdir -p .github/ISSUE_TEMPLATE
cat > .github/ISSUE_TEMPLATE/bug_report.md <<'EOF'
## Bug 描述
<!-- 简洁描述问题 -->
## 复现步骤
1.
2.
3.
## 预期行为
<!-- 应该发生什么 -->
## 实际行为
<!-- 实际发生了什么 -->
## 环境
<!-- 操作系统、Node 版本等 -->
EOF
git add .github
git commit -m "Add bug report template"
git push
Output
[main 5d2e1a4] Add bug report template
1 file changed, 17 insertions(+)
create mode 100644 .github/ISSUE_TEMPLATE/bug_report.md
To https://github.com/<your-username>/hello-github-demo.git
8a3f2c1..5d2e1a4 main -> main
remote: Create a pull request for 'main' on GitHub by visiting:
remote: https://github.com/<your-username>/hello-github-demo/pull/new/main
Narration
.github 目录是 GitHub 的特殊配置目录，模板放这里后，下次点 "New issue" 就会自动出现表单模板。你会看到 "Bug report"、"Feature request" 等选项——这就是模板的威力。这把"你必须填什么"前置到创建环节，避免出现"登录坏了"这种一句话 Issue——没有复现步骤的 Issue 只能被无限期搁置。模板字段提醒填写者：问题是什么、怎么复现、预期什么、实际什么、环境是什么——这五项填齐，开发者就能直接动手修。
Demo 3.2：用 Closes 关键字联动 PR
Screen
浏览器，仓库 Issues 标签页，点击绿色 "New issue" 按钮，选择 "Bug report" 模板。表单弹出，按提示填写。
Command
# 假设在网页填写并提交 Issue #1：
# Title: app.js 没有处理空字符串情况
# 然后在本地修复并发起 PR：
git checkout -b fix/empty-string
echo "// TODO: add input validation" >> app.js
git add app.js
git commit -m "Mark validation TODO"
git push -u origin fix/empty-string
# 发起 PR，描述里写: "Closes #1"
# 合并后回到 Issue #1 页面观察
Output
✓ Merged pull request #2: Handle missing console
• demo merged 2 commits into main
• fix/empty-string has been deleted
Closed via commit 9c1d4ab on main
demo closed this in #2 just now
Narration
Closes #1、Fixes #1、Resolves #1 都是 GitHub 识别的关键字——PR 合并时自动关闭对应 Issue。回到 Issue #1 页面，你会看到状态变成 "Closed"，底部显示"closed via commit xxx in PR #2"——完整追溯链：哪个 PR、哪个 commit、什么时候关的。这是把代码交付和任务追踪绑定的关键魔法，避免出现"代码合并了但 Issue 还开着"的扯皮。所有相关方点开 Issue 就能看到完整的解决过程，沟通成本接近零。
本章小结
- 关键收获：Issue 模板前置信息收集，Closes 关键字联动 PR 自动关闭任务
- 使用场景：所有需要追踪 bug、需求、优化的项目，尤其 3 人以上的团队
- 过渡：手动测代码太累，能不能 push 完就自动测？下一章我们用 GitHub Actions 实现这个
第四章：GitHub Actions 自动化（6:45–9:15）
本章目标
能写第一个 CI workflow，理解 push 触发 → Runner 执行 → 状态回传 PR 的完整闭环。掌握 workflow YAML 的核心结构：触发器、jobs、steps、actions。
为什么需要 CI/CD
每次 push 后手动 npm test、npm run build、部署到服务器——一天 10 次，一周 50 次，这些机械劳动纯粹是浪费人。GitHub Actions 是 GitHub 内置的自动化引擎，零额外基础设施成本：代码 push → 自动测试 → 自动部署 → 失败自动通知，你只负责写代码。
Demo 4.1：编写第一个 CI workflow
Screen
终端，仓库根目录。准备在 .github/workflows/ 下创建 CI 配置文件。
Command
mkdir -p .github/workflows
cat > .github/workflows/ci.yml <<'EOF'
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci || echo "no package.json, skipping"
- run: node app.js
EOF
git add .github/workflows/ci.yml
git commit -m "Add CI workflow"
git push
Output
[main 7f9b3c2] Add CI workflow
1 file changed, 22 insertions(+)
create mode 100644 .github/workflows/ci.yml
remote: Resolving deltas: 100% (1/1), done.
To https://github.com/<your-username>/hello-github-demo.git
5d2e1a4..7f9b3c2 main -> main
Narration
YAML 里的 on 是触发器，push 和 pull_request 表示只要代码进了 main 或者 PR 指向 main 就跑——这两个事件覆盖了 99% 的 CI 场景。runs-on: ubuntu-latest 表示用最新 Ubuntu 虚拟机，每次都是全新环境，所以 CI 不会污染本地环境，也不会有"我电脑上能跑"的问题。Steps 顺序执行：先 actions/checkout@v4 把代码拉到 Runner，再 actions/setup-node@v4 装 Node 20，最后跑两条命令。注意 Action 必须固定版本号 @v4，绝不能用 @latest——后者某天会引入不兼容更新，你的 CI 突然就挂了。每个 Step 之间默认串行，可以加 needs 关键字定义依赖关系。
Demo 4.2：在 PR 页面看 CI 结果
Screen
浏览器，发起一个 PR（任改一个文件即可），刷新 PR 页面。底部出现 "Checks" 区域。
Command
# 在 PR 的 Checks 区域可以看到：
# ✓ CI / test (pull_request) — Successful in 23s
# 点击 "Details" 可以看到每一步的日志
echo "查看 PR 页面底部 Checks 标签页"
Output
All checks have passed
✓ CI / test — 23s
✓ Set up job
✓ Run actions/checkout@v4
✓ Run actions/setup-node@v4
✓ Run npm ci || echo "no package.json, skipping"
✓ Run node app.js
✓ Complete job
Narration
CI 是 PR 合并的"门禁"，也是代码质量的自动守门人。状态会实时回传到 PR 页面——通过就是绿色对勾 ✓，失败就是红色叉号 ✗，悬而未决是黄色圆点（表示还在跑）。如果配了分支保护规则（Settings → Branches → Branch protection rules，勾选 "Require status checks to pass before merging"），没通过 CI 的 PR 连 Merge 按钮都点不了——这是强制质量门槛，再粗心大意的开发者也合并不进去坏代码。点 "Details" 进去能看到完整日志：每一步的命令、标准输出、错误输出、耗时多少秒。失败时，日志会精确告诉你哪一行挂了、报错是什么，不用本地复现就能定位问题。这就是 Actions 相比手动测试的最大优势：完全可追溯、可重放、可分享——任何团队成员打开链接都能看到同一份日志。
本章小结
- 关键收获：YAML workflow 定义"何时触发 + 跑什么命令"，Runner 是 GitHub 提供的云端虚拟机，状态实时回传 PR
- 使用场景：所有需要测试、构建、部署自动化的项目，从开源小项目到企业内部系统
- 过渡：四个模块——仓库、Flow、Issues、Actions——都跑过了。最后我们把它们串成一个端到端实战
第五章：综合实战项目（9:15–9:50）
本章目标
把仓库创建、分支策略、Issue 追踪、CI 自动化四件套串成一个端到端流程。从需求提出到代码合并、任务关闭，全程不离开 GitHub。
Demo 5.1：完整跑通 GitHub Flow + Actions
Screen
浏览器和终端并排。仓库是前面章节创建的 hello-github-demo，已配好 CI workflow。
Command
# 1. 在 GitHub 页面创建 Issue #2：标题 "重构 app.js 为可测试模块"
# 2. 在本地拉分支开发
git checkout -b refactor/modular-app
mkdir -p src
mv app.js src/index.js
cat > package.json <<'EOF'
{
"name": "hello-github-demo",
"version": "1.0.0",
"scripts": {
"test": "node src/index.js"
}
}
EOF
git add .
git commit -m "Refactor: split into src/ module with package.json"
git push -u origin refactor/modular-app
# 3. 在网页发起 PR，描述里写 "Closes #2"
# 4. 等待 CI 通过（绿色 ✓）
# 5. 点击 "Squash and Merge"
Output
[refactor/modular-app b2e7a13] Refactor: split into src/ module with package.json
3 files changed, 9 insertions(+)
create mode 100644 package.json
create mode 100644 src/index.js
✓ CI passed in 18s
✓ Merged refactor/modular-app into main
✓ Issue #2 closed by PR #3 automatically
Narration
这就是完整的 GitHub 协作闭环：Issue 提出需求 → feature 分支开发 → PR 关联 Issue（写 Closes #2）→ CI 自动验证 → 合并后 Issue 自动关闭。全程不需要线下沟通，GitHub 自己把任务、代码、质量三件事串起来。你会看到 Issue #2 自动从 Open 列表消失，状态变成 Closed，并标注"closed by PR #3"。所有相关方——产品经理、开发者、Reviewer——点开 Issue 都能看到完整解决链：哪个 PR、哪些 commit、CI 是不是通过、什么时候合并的。这就是 GitHub 的"单源真相"：一切以 GitHub 上的状态为准，不用反复同步"现在做到哪了"。
课程收尾（9:50–10:00）
10 分钟我们跑完了现代软件团队的标准协作工作流：仓库创建 → GitHub Flow 分支策略 → Pull Request 审查 → Issues 任务追踪 → Actions 自动测试。这是一条经过全球数百万开发者验证的高效路径，覆盖了从需求提出到代码上线的完整链路。
你现在具备的能力：用 PR 而非直接 push 协作；写可追踪的 Issue 和 PR 描述；配一个最简 CI workflow；理解关键字联动 PR 和 Issue 的自动化。
下一步建议：第一，在自己的真实项目里跑一遍这个流程，配上分支保护规则（Settings → Branches 开启"Require status checks to pass before merging"）；第二，找一个你感兴趣的开源项目——比如 popular 的文档项目或小工具——通过 Issue + PR 贡献代码。真实协作比练习 100 次都有效，你会遇到陌生开发者的 Review 风格、不同项目的 CI 配置、各种奇妙的分支命名约定——这些是 GitHub 文档教不了你的。
掌握 GitHub 的核心是掌握 PR 这个抽象——它把"提交代码"升级成"请求合并 + 触发讨论 + 触发自动化"。一旦理解这一点，所有 GitHub 功能都是这个原型的延伸。开始你的第一次 PR 吧。
实践示例
创建远程仓库并推送到 GitHub
创建 feature 分支并发起 Pull Request
审查并合并 Pull Request
使用 Issues 模板和 Closes 关键字自动关闭任务
编写 GitHub Actions CI workflow 实现自动化测试
引用此知识点
- 命令行演示教程：10 分钟从图形界面走向键盘自由前置
面向零基础初学者的命令行实操教程，10 分钟从打开终端开始，讲解 Shell、Terminal、PATH 核心概念，演示文件系统操作、管道重定向与文本处理，并编写 Shell 脚本完成日志分析报告生成器。
- Docker 演示教程：一次打包，到处运行后续
面向初学者的 Docker 实操教程，10 分钟演示镜像与容器概念、Dockerfile 构建、Docker Compose 多服务编排、常用排错命令，并通过 Node.js + nginx + PostgreSQL 博客项目实战完成容器化部署。
- IDE 演示教程：从毛坯房到编程超能力相关
面向初学者的 IDE 实操教程，10分钟演示 VS Code 从默认配置到高效开发环境的调教，涵盖 IDE 核心概念（智能补全与语言服务器）、按语言选择 IDE 与安装扩展、个性化 settings.json 配置、安装 GitLens 与 GitHub Copilot 等实用插件，以及团队级 .vscode 配置实战，实现效率提升。