title: " GitHub全流程 | 注册到部署一篇通" category: 人工智能 tags:


前面几篇我们一直在聊 Hermes、SpecKit、Kiro、OpenSpec、Coding Agent 和多模型接入。真正落到工程现场,你会发现所有工具最后都绕不开一个地方:GitHub。

不管你用 Codex、Claude Code、Cursor、ZCode,还是通过 4SAPI 这类大模型API中转站接入多模型,Agent 真正开始干活时,通常都要读仓库、改文件、跑测试、提交 commit、推分支、开 Pull Request。也就是说,GitHub 不只是代码托管网站,而是 AI 编程工作流的“协作地板”。

这篇文章不假设你已经熟悉 GitHub。我会从注册账号、双重认证、搜索项目、创建仓库、写 Issue、本地 Git、Pages 部署、Fork、Star、Pull、Push 一路讲完。下一篇再专门讲 Codex 和 Claude 是怎么自动化使用 Git 的。

1. GitHub 到底是什么

一句话理解:

Git 是本地版本控制工具。
GitHub 是基于 Git 的在线协作平台。

Git 负责记录代码历史,比如你改了哪些文件、什么时候改的、能不能回退。

GitHub 负责多人协作,比如远程仓库、Issue、Pull Request、代码审查、Actions 自动化、Pages 部署、项目看板、权限管理。

可以把 GitHub 的核心对象记成 8 个词:

名词 作用 新手要记住什么
Repository 仓库,存代码和文档 一个项目通常对应一个仓库
Branch 分支 新功能不要直接改主分支
Commit 一次变更记录 写清楚“为什么改”
Push 把本地提交推到 GitHub 本地到远程
Pull 拉取远程更新到本地 远程到本地
Issue 任务、Bug、需求讨论 先描述问题,再动手改
Pull Request 请求合并代码 让别人审查你的分支
Actions/Pages 自动化和部署 可做测试、构建、静态站发布

如果你只把 GitHub 当网盘用,会很难发挥它的价值。正确姿势是:Issue 管问题,Branch 做改动,Pull Request 做审查,Actions 做验证,Pages 做展示。

2. 注册 GitHub 账号:先把身份打稳

注册入口很简单:

https://github.com

注册时会让你填写邮箱、密码、用户名。这里有几个容易忽略的小点。

第一,用户名尽量长期可用。

GitHub 用户名会出现在仓库地址、提交记录、个人主页里,例如:

https://github.com/yourname/your-repo

如果你后面要做开源、写技术文章、放作品集,用户名最好简洁、专业、容易拼写。

第二,邮箱要能长期接收邮件。

GitHub 会要求验证邮箱。团队邀请、Issue 提醒、安全通知、PR 评论提醒,都可能通过邮箱送达。不要用随时可能丢的临时邮箱。

第三,个人账号和组织账号不是一回事。

个人账号代表你本人;组织账号代表团队、公司或开源项目。个人账号可以加入多个组织。新手先创建个人账号,后面团队协作时再建组织。

第四,公开资料别乱填敏感信息。

头像、Bio、公司、位置、个人网站都可以展示职业形象,但不建议把手机号、私人邮箱、公司内网地址、API Key 之类信息写进去。

一个比较稳的初始化清单:

1. 注册账号。
2. 验证邮箱。
3. 设置头像和简介。
4. 配置双重认证。
5. 再配置本地 Git 和 SSH/Token。

不要跳过第4步。GitHub 账号一旦被盗,攻击者拿到的不只是你的代码,还可能拿到私有仓库、发布权限、CI Secret 和公司组织权限。

3. 双重认证:别等账号丢了才补安全

双重认证通常叫 2FA。它的意思是:登录时除了密码,还要第二个因素,比如手机认证器、Passkey、安全密钥或 GitHub Mobile。

GitHub 官方从 2023 年 3 月开始要求为 GitHub.com 上贡献代码的用户启用一种或多种 2FA。即便你只是个人学习,也建议第一天就开。

推荐顺序:

方式 推荐度 说明
TOTP 认证器 常见、稳定,适合大多数人
Passkey 可用 Windows Hello、Face ID、Touch ID 等
安全密钥 适合高安全需求
GitHub Mobile 适合移动端确认
SMS 短信 易受拦截,且部分地区不可用

开启路径大致是:

右上角头像 -> Settings -> Password and authentication -> Two-factor authentication

用 TOTP 时,可以选 1Password、Bitwarden、Microsoft Authenticator、Google Authenticator 等工具。扫码后会出现 6 位动态验证码,在 GitHub 页面输入即可。

最关键的一步是保存恢复码。

Recovery codes 不是摆设。
手机丢了、认证器删了、Passkey 不可用时,它就是你找回账号的后门钥匙。

建议把恢复码保存到密码管理器,并额外离线备份一份。不要发到微信、飞书群、邮件正文里,更不要提交到 GitHub 仓库。

4. 2FA 之后,本地 Git 怎么登录

很多新手会在这里卡住:

网页能登录 GitHub,
但 git push 时一直提示账号密码错误。

原因是:GitHub 早已移除 Git 操作里的密码认证。命令行访问通常用两种方式:

方式 适合谁 特点
HTTPS + Personal Access Token 新手、公司网络环境复杂 URL 直观,可配 Git Credential Manager
SSH Key 高频开发者、长期项目 不用每次输 Token,体验稳定

如果你选择 HTTPS,建议安装 GitHub CLI 或 Git Credential Manager,让系统安全地记住凭据。不要把 Token 明文写进脚本或仓库。

如果你选择 SSH,流程是:

ssh-keygen -t ed25519 -C "your_email@example.com"

然后把公钥加入 GitHub:

Settings -> SSH and GPG keys -> New SSH key

测试 SSH:

ssh -T git@github.com

HTTPS 地址长这样:

https://github.com/username/repo.git

SSH 地址长这样:

git@github.com:username/repo.git

两者都能用。团队里最怕的是一半人用 HTTPS、一半人用 SSH,却没人知道自己本地 remote 配了什么。先用下面命令看清楚:

git remote -v

如果要改地址:

git remote set-url origin git@github.com:username/repo.git

5. 搜索:GitHub 的第一生产力

会搜 GitHub,比会收藏一堆链接更重要。

普通搜索可以找仓库、代码、Issue、PR、用户、组织。新手最常用的是仓库搜索和代码搜索。

5.1 搜仓库

比如你想找最近还在维护的 Python 爬虫项目:

web crawler language:Python stars:>1000 pushed:>2025-01-01 archived:false

常用限定词:

查询 含义
language:Python 限定主要语言
stars:>1000 Star 数超过 1000
forks:>100 Fork 数超过 100
pushed:>2025-01-01 最近提交时间在 2025-01-01 之后
topic:agent 带有 agent 主题
license:mit MIT License
archived:false 排除归档仓库
org:openai 限定组织
user:octocat 限定用户

找 AI 编程工具可以这样搜:

coding agent language:TypeScript stars:>500 pushed:>2025-01-01

找 OpenAI-compatible 服务:

"OpenAI compatible" language:Go stars:>100 pushed:>2025-01-01

找 Claude 相关项目:

claude code language:TypeScript stars:>100 archived:false

如果你是做大模型API中转站选型,也可以搜:

openai proxy language:Go stars:>500 pushed:>2025-01-01

搜索结果不要只看 Star。还要看:

最近一次提交时间
Issue 是否有人回复
Release 是否稳定
README 是否清楚
License 是否允许你的用途
安全问题是否及时修

5.2 搜代码

代码搜索适合找真实用法。

比如你想看别人怎么写 GitHub Actions 部署 Pages:

"actions/deploy-pages" path:.github/workflows language:YAML

想找某个仓库里的配置:

repo:owner/repo filename:package.json

想找某个路径下的函数名:

repo:owner/repo path:src symbol:createClient

代码搜索常用限定词:

查询 含义
repo:owner/repo 限定某个仓库
org:github 限定组织
language:TypeScript 限定语言
path:src 限定路径
symbol:UserService 搜符号定义
"exact phrase" 精确短语
A OR B 二选一
NOT path:test 排除测试路径

GitHub 代码搜索还支持用 /.../ 包住正则。比如:

/api[_-]?key/i NOT path:test

搜索密钥泄露时要非常谨慎。不要把别人的泄露 Key 拿来试,更不要传播。看到疑似泄露,正确做法是通知维护者或走安全报告渠道。

6. Star、Watch、Fork:三个按钮别混

仓库右上角常见三个动作:Star、Watch、Fork。

动作 你在做什么 适合场景
Star 收藏/认可项目 以后再看、表达支持
Watch 订阅通知 关注 Issue、Release、PR 动态
Fork 复制一份到自己账号 准备修改并提交 PR

Star 不是下载,Fork 也不是点赞。

Star 更像收藏夹。你可以在个人主页的 Stars 列表里找回项目,也可以用列表整理。

Watch 会带来通知。不要随手 Watch 大型热门仓库,否则邮箱和通知中心会很吵。

Fork 是协作动作。你没有原仓库写权限时,先 Fork 到自己账号,在自己的 Fork 上改代码,再向原仓库提交 Pull Request。

7. 创建仓库:别只会点 New repository

新建仓库入口:

右上角 + -> New repository

创建时要决定几件事。

第一,Owner。

仓库属于个人还是组织。个人练习就选自己;团队项目选组织。

第二,Repository name。

推荐小写、短横线、语义清楚:

ai-gateway-demo
github-action-starter
claude-codex-workflow

第三,Visibility。

可见性 含义 建议
Public 全网可见 开源项目、作品展示
Private 只有授权用户可见 公司项目、未发布产品、含敏感逻辑

第四,README。

新项目建议勾选。README 是仓库首页,也是 AI Coding Agent 理解项目的入口之一。

第五,.gitignore

根据语言选择模板,比如 Node、Python、Java、Go。它能避免把 node_modules、虚拟环境、构建产物、日志文件提交上去。

第六,License。

开源项目一定要选 License。没有 License,不代表“随便用”,反而通常意味着别人没有明确授权。

一个实用的 README 最少包含:

项目是什么
如何安装
如何运行
如何测试
关键目录说明
环境变量说明
贡献方式

如果你要让 Codex 或 Claude 帮你改项目,README 里写清楚命令非常有价值:

npm install
npm run dev
npm test
npm run lint

Agent 不怕项目复杂,怕的是项目没有入口、没有测试、没有约束。

8. Issue:把问题写清楚,代码才不乱改

Issue 是 GitHub 协作里最容易被低估的功能。

它不只是“报 bug”。它可以是:

Bug 反馈
新功能需求
重构计划
文档任务
性能优化
安全问题跟踪
设计讨论
验收清单

一个好 Issue 应该包含:

内容 为什么重要
背景 让读者知道为什么要做
当前行为 现在发生了什么
期望行为 你希望发生什么
复现步骤 Bug 能不能稳定重现
环境信息 系统、版本、浏览器、依赖
验收标准 做到什么才算完成

可以直接套这个模板:

## 背景

这里说明为什么要做这件事。

## 当前问题

现在的行为是什么?有什么影响?

## 期望结果

希望改成什么样?

## 复现步骤

1. 进入页面/运行命令
2. 输入什么
3. 看到什么错误

## 验收标准

- [ ] 新逻辑能通过测试
- [ ] 文档已更新
- [ ] 不影响原有接口

GitHub Issue 可以加标签、负责人、里程碑、项目看板。小团队不一定一上来就复杂化,但至少建议有这些标签:

bug
feature
docs
good first issue
help wanted
security
performance

如果你准备让 AI Agent 接手,Issue 更要写清楚。模糊的 Issue 会让 Agent 猜需求,猜需求往往比写代码更危险。

比较好的 Agent 任务写法:

请修复登录页在邮箱为空时仍然提交表单的问题。

要求:
1. 只修改登录表单相关代码。
2. 增加一个单元测试覆盖空邮箱场景。
3. 保持现有错误提示样式。
4. 运行 npm test 和 npm run lint。
5. 提交 PR,说明改动和验证结果。

这比一句“登录页有 bug,修一下”靠谱得多。

9. 本地 Git:从零到第一次 Push

安装 Git 后,先配置身份:

git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"

这个名字和邮箱会写进 commit。它不等于 GitHub 登录账号,但 GitHub 会用邮箱把 commit 关联到你的账号。

9.1 克隆已有仓库

git clone git@github.com:username/repo.git
cd repo

查看状态:

git status

查看分支:

git branch

新建分支:

git switch -c feature/login-validation

修改文件后:

git status
git diff
git add .
git commit -m "Add login email validation"
git push -u origin feature/login-validation

然后到 GitHub 页面创建 Pull Request。

9.2 本地已有项目,推到 GitHub

假设你本地已经有一个项目:

cd my-project
git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin git@github.com:username/my-project.git
git push -u origin main

如果 origin 已经存在,别重复 git remote add,用:

git remote set-url origin git@github.com:username/my-project.git

9.3 Pull 和 Push 的心智模型

记住这张表就够了:

命令 方向 含义
git clone GitHub -> 本地 第一次复制仓库
git pull GitHub -> 本地 拉取并合并远程更新
git fetch GitHub -> 本地 只拿远程信息,不合并
git push 本地 -> GitHub 推送本地提交
git remote -v 查看 看本地连着哪个远程仓库

git pull 可以理解为:

git fetch + git merge

如果你担心远程改动影响本地,可以先:

git fetch origin
git diff main..origin/main

确认没问题再合并或 rebase。

10. 常见 Git 报错怎么排

10.1 Authentication failed

常见原因:

还在用密码登录 Git。
Token 过期或权限不足。
SSH key 没加到 GitHub。
remote URL 写错。

排查:

git remote -v
ssh -T git@github.com
gh auth status

如果是 HTTPS,确认使用的是 Personal Access Token,而不是 GitHub 密码。

10.2 Non-fast-forward

常见提示:

Updates were rejected because the remote contains work that you do not have locally.

意思是远程有你本地没有的提交。先拉:

git pull --rebase origin main

解决冲突后再:

git push

团队项目里不要随便 git push --force。如果必须强推,优先用:

git push --force-with-lease

10.3 合并冲突

冲突不是错误,是两边改了同一块内容。

流程:

git status
打开冲突文件
保留正确内容
删除 <<<<<<< ======= >>>>>>> 标记
git add 冲突文件
git rebase --continue

如果你不确定怎么取舍,不要硬合。先问维护者,或者在 PR 里说明冲突点。

10.4 提交了不该提交的文件

比如 .env、Key、数据库文件、构建产物。

先把规则写进 .gitignore

.env
node_modules/
dist/
*.log

如果敏感信息已经 push 到公开仓库,不是删除文件就完事。要立刻吊销 Key、重新生成,再清理历史。泄露过的 Key 要默认已经失效。

11. GitHub Pages:把静态站部署出去

GitHub Pages 适合部署静态网站,比如个人主页、文档站、项目 Demo、博客构建产物。

最简单流程:

1. 仓库里放 index.html。
2. 进入 Settings。
3. 找到 Pages。
4. Source 选择 Deploy from a branch。
5. Branch 选择 main,目录选择 / 或 /docs。
6. 保存后等待构建完成。

如果你用 Vite、Next.js 静态导出、Astro、Docusaurus、VuePress 这类工具,更推荐用 GitHub Actions 构建后部署。

典型流程:

push 到 main
  -> GitHub Actions 安装依赖
  -> 构建静态文件
  -> 上传 Pages artifact
  -> 部署到 GitHub Pages

部署时注意:

问题 建议
404 检查输出目录和 base path
CSS/JS 加载失败 检查站点子路径
构建失败 看 Actions 日志
私密内容泄露 Public Pages 不要放内部文档
自定义域名 配置 DNS 和 CNAME

GitHub Pages 很适合放技术文章配套 Demo。比如你写一篇 4SAPI 接入教程,可以把最小 HTML 示例、请求示例、部署结果放到 Pages,让读者点开就能看。

12. Fork 和 Pull Request:参与开源的标准姿势

你没有别人仓库的写权限时,不能直接 push。标准流程是 Fork + Pull Request。

步骤如下:

1. 打开原仓库。
2. 点击 Fork,复制到自己账号。
3. Clone 自己的 Fork 到本地。
4. 添加 upstream 指向原仓库。
5. 新建分支修改。
6. Push 到自己的 Fork。
7. 在 GitHub 上创建 Pull Request。

命令示例:

git clone git@github.com:yourname/project.git
cd project
git remote add upstream git@github.com:original-owner/project.git
git switch -c fix/readme-typo

修改后:

git add README.md
git commit -m "Fix README typo"
git push -u origin fix/readme-typo

同步原仓库更新:

git fetch upstream
git switch main
git merge upstream/main
git push origin main

也可以用 rebase:

git fetch upstream
git switch fix/readme-typo
git rebase upstream/main
git push --force-with-lease

PR 描述建议包含:

## 做了什么

- 修复 README 中的命令拼写。

## 为什么

- 原命令无法直接运行。

## 如何验证

- 本地运行 `npm test`。
- 手动执行 README 中的安装命令。

维护者不是只看代码,他们还看你是否尊重项目风格、是否给出验证、是否把改动控制在合理范围内。

13. Issue、Branch、PR 的推荐闭环

一个成熟团队不会直接在主分支上乱改。推荐闭环是:

Issue 描述问题
  -> Branch 承载改动
  -> Commit 记录历史
  -> Push 上传分支
  -> Pull Request 发起审查
  -> Actions 自动测试
  -> Review 通过
  -> Merge 合并
  -> Close Issue

对应命令:

git switch main
git pull --rebase origin main
git switch -c feature/issue-123-login-validation

# 修改代码
git status
git diff
git add .
git commit -m "Validate login email before submit"
git push -u origin feature/issue-123-login-validation

PR 标题可以关联 Issue:

Fix #123: validate login email before submit

GitHub 支持通过关键词自动关闭 Issue,比如:

Closes #123
Fixes #123
Resolves #123

把这套流程跑顺以后,再引入 Codex 或 Claude 才会稳。

14. AI Coding Agent 为什么更需要 GitHub 基础

现在很多人第一次接触 GitHub,不是因为开源,而是因为 AI 编程工具。

Codex、Claude Code、Cursor 这类工具可以帮你:

读代码
找 bug
改文件
写测试
生成 commit message
创建 PR
审查 PR
修复 CI 失败
更新文档

但它们不能替你做工程判断。你还是要知道:

当前在哪个分支
改了哪些文件
有没有误删
测试是否通过
PR 合并到哪里
Token 有没有泄露
能不能直接 push

如果你把 4SAPI 作为统一模型入口,确实可以更方便地管理 Claude、GPT、GLM、DeepSeek 等模型调用成本。但 GitHub 权限仍然是另一套系统:GitHub Token、SSH Key、组织权限、分支保护、Actions Secret 都要单独管理。

不要把“模型能写代码”理解成“模型可以绕过 Git 规范”。真正高效的 AI 编程,是让 Agent 进入现有工程流程,而不是把流程打碎。

15. 新手最小练习路线

如果你想快速练熟 GitHub,不要只看教程。按下面做一遍:

1. 注册 GitHub 账号并开启 2FA。
2. 配好 SSH Key 或 HTTPS Token。
3. 新建一个 public 仓库。
4. 写一个 README 和 index.html。
5. Clone 到本地。
6. 新建分支修改 README。
7. Commit 并 push。
8. 创建 Pull Request。
9. Merge 后删除分支。
10. 开启 GitHub Pages。
11. Fork 一个练习仓库。
12. 提交一个小 PR。

这 12 步跑完,你就不再是“只会下载 zip”的 GitHub 用户了。

16. 总结

GitHub 的核心不是“上传代码”,而是围绕代码形成一套可追踪、可审查、可自动化的协作流程。

新手优先掌握这几件事:

能力 关键词
账号安全 2FA、恢复码、SSH、Token
找项目 搜索限定词、Star、Watch
管项目 Repository、README、License、.gitignore
管任务 Issue、Label、Milestone、验收标准
写代码 Branch、Commit、Push、Pull
做协作 Fork、Pull Request、Review
做部署 GitHub Pages、Actions

下一篇我们继续往前走:当 GitHub 基础打稳后,Codex 和 Claude Code 怎么自动化读 Issue、开分支、改代码、跑测试、提交 commit、创建 PR、处理 review?这才是 AI Coding Agent 真正进入团队研发流程的关键。

参考资料: