GitHub 从入门到精通（精炼版）：30 分钟跑通建仓、提交与协作
你本来只是想装个小工具。
搜到官网，点开链接------然后愣住了。屏幕上铺满了你看不太懂的东西：Code、Issues、Pull Requests、Actions、Releases......绿色的按钮倒是有七八个，没一个是你想要的。
你盯着屏幕看了会儿，手指悬在鼠标上，心里只有一个问题：
「下载按钮到底在哪儿？」
这篇文章分「入门」和「进阶」两部分。入门篇大约 30 分钟，能跑通「建仓 → 读仓 → 日常提交」这条完整的线，没接触过 Git 的人也能一路跟下来；进阶篇讲团队协作、开源贡献、自动化交付和翻车救急。不用从头读到尾，卡在哪一步，直接翻到对应章节就行。
第一部分 · 入门篇：30 分钟跑通闭环
1. 先分清 Git 和 GitHub
- Git：装在电脑上的版本管理工具，负责记录每次修改、支持回退，离线也能用。
- GitHub：承载远端仓库的平台，把项目内容、修改历史、问题讨论、协作和发布集中在同一处。
不会写代码也有三种用法：找项目 （README 看安装、Issues 查已知问题、Releases 下正式版本）、保存成果 （文档、脚本、个人网站，换电脑不丢）、参与协作（开 Issue、发 PR，改错字补说明也算贡献）。
2. 用浏览器建第一个仓库
- 注册 → 验证邮箱 → 开启双重验证。恢复代码存密码管理器，别混进仓库和聊天记录。
- New repository → 命名（比如
github-first-project）→ 按内容选 Public/Private → 勾选 README。 - 在网页里编辑 README，提交信息写清楚（比如
docs: add project introduction），完成第一次 commit。 - 建一个分支（比如
docs/web-edit）再提交，体会「分支隔离改动，main 不受影响」。
先别纠结命令，动起来最重要，正反馈来得快。
3. 看懂别人的仓库，找对下载入口
先看六组入口：
- 作者名/仓库名：确认项目归属，下载前把作者和仓库名一起核对。
- README：第一份使用说明，英文太长时先找 Installation、Usage、Requirements、License。
- 文件列表：认常见约定（README.md、LICENSE、src/、scripts/、docs/、.github/），比逐个点开高效。
- Commits / Branches / Tags：提交记录、分支隔离、版本标签，看的是不同的事。
- Issues / PR / Actions：问题讨论、修改合并、自动检查------绿勾通过，红叉进日志看哪一步失败。
- Stars / Forks：只反映热度，不证明质量。更该看最近提交时间、README 完整度、Release 更新频率、Issues 是否有大量同类故障。
下载三选一：
| 方式 | 适用场景 | 注意 |
|---|---|---|
| Download ZIP | 一次性查看文档、拿素材 | 无 Git 历史，作者更新后本地不会变 |
| Clone | 长期跟踪、修改、继续开发 | 复制完整版本历史，可拉取更新；需先配好 Git 凭据（SSH 或 HTTPS 密钥）才能长期流畅使用 |
| Release | 拿作者正式交付的版本 | 别把自动生成的源码归档当安装包，先读文件名 |
真正要多看的三眼：①发布者与维护状态；②README 与 Issues 里的已知问题；③License 是否允许你的用途。
AI 可以帮你读文档、解释目录和报错，但下载地址是否官方、许可是否合规、命令会获得什么权限这三件事，得自己确认。
4. Git 的四个位置和日常三连
四个位置与流向（工作区 → 暂存区 → 本地库 → GitHub）：
bash
git status # 先看变化
git add . # 加入暂存（. 代表当前目录下所有变化）
git commit -m "docs: update README"
git push # 同步远端记住这一条，很多疑问都能解释：文件改了但网页没变 ，说明改动还在工作区；commit 了但网页没更新，说明提交还在本地。每次 commit 只处理一组相关修改。
连不上 GitHub？先查网络 。本地版本库到 GitHub 之间隔着一条「网络线」。没梯子、代理配置错、网络超时，都会让你卡死在 git push 这一步。这不是 Git 的锅，先查网络连通性和代理设置，再回头看命令。
克隆到电脑，推回远端：
- 安装 Git（Windows 用 Git for Windows），只做一次身份设置：
git config --global user.name "你的署名"+git config --global user.email "关联邮箱"。 - 登录方式三选一：HTTPS + 凭据管理 、GitHub CLI （
gh auth login）、SSH 密钥。账号密码已经不能直接当 Git 密码用。 git clone <地址>后cd进目录、git status，看到working tree clean即就绪。- 新增
index.html，走完status → add → commit → push，回网页确认文件和提交都出现。 - push 前先
git fetch看本地是否落后，落后再git pull。不要盲目强推------可能覆盖远端历史。 - 本地分支合并，把「分支隔离」闭环走通 ：第 2 章建的
docs/web-edit分支，切回主线git switch main，再git merge docs/web-edit把分支改动合回 main，最后git branch -d docs/web-edit删掉旧分支。这就是团队 PR 合并前，本地最简的同款体验。
怕命令行？GUI 就是这些命令的按钮。VS Code、Cursor、WebStorm 自带的「源代码管理」面板，把上面的 status/add/commit/push/pull/merge 全做成了按钮。点一下等于敲一条命令，分支和差异看得一清二楚。先在上面点，慢慢就懂命令在做什么了。
fetch 和 pull 差在哪 。git fetch 只把远端的新提交下载 到本地，不动你正在做的内容；git pull 其实是 git fetch + git merge 连做两步------先下载、再自动合并。新手高频翻车点就在这里：以为 pull 只是"下载"，结果本地悄悄多出一个 Merge 提交。只想"看看远端有什么、先不动本地"，用 git fetch；确定要同步，再用 git pull。
本地已经写好的项目，怎么传上去？ 前面的路径是先网页建仓再 clone，反过来也一样顺。本地已有项目时三步搞定：
bash
git init # 1. 在项目目录初始化
git remote add origin <仓库地址> # 2. 连上远端（地址从 GitHub 仓库 Code 菜单复制）
git push -u origin main # 3. 推上去（-u 建立跟踪关系）第二部分 · 进阶篇：团队协作、自动化与救急
5. 真实团队协作流：Issue → 分支 → PR
生命周期循环（Issue → Branch → PR → Main，闭环复用）：
- 开 Issue 说清任务；报错类补上系统版本、操作步骤、完整报错。
- 确认连的是谁的仓库 ：协作第一步先
git remote -v，看自己连的远端地址到底是谁的------团队里最容易在这步连错仓库。 - 建分支 ：
git switch main && git pull && git switch -c docs/add-usage------先回主线、拉最新、再开新线，这就是行业黑话「保持主线干净」，一项任务一个分支。 - 提交推送 ：
git commit -m "docs: add usage instructions"+git push -u origin 分支名。 - 创建 PR ：base 指向 main，compare 指向分支；描述写
Closes #1（合并后回 Issue 检查是否真的自动关闭）。 - 合并前自己 review：文件数量是否异常、红绿改动有没有误删、自动检查是否通过。
- 合并 → 确认 Issue 状态 → 删除已合并的分支（删除分支不会删除已合并的提交）。
Stash：写一半先存起来 。写到一半，突然要紧急切去修别处的 Bug？
git stash把当前写一半的代码存入「临时寄存箱」，切走修完 Bug 回来，再用git stash pop取出继续写。切换分支再也不怕半成品丢失。
PR 冲突的黄金法则 ：发 PR 前（或 PR 提示冲突时），别在网页上硬点、也别等合回 main 时硬碰硬。先在本地分支 git merge main（或 git rebase main）把冲突解决掉，再 push------确保推上去的 PR 是绿的，别人 review 起来也更轻松。
6. 参与开源：Fork 模式
- Clone 只把仓库复制到电脑，不会自动给你向原仓库 push 的权限。
- Fork 在自己账号下创建一份关联副本，改完向原作者发跨仓库 PR（base 指向原作者仓库，compare 指向你的 fork）。
标准贡献路径：读 README/License/CONTRIBUTING → Fork → clone 自己的 fork → 添加 upstream → 同步 main → 建分支 → 修改 → 发 PR。第一次贡献从文档错字、失效链接、good first issue 这类边界清晰的小任务开始。
Fork 之后原作者更新了代码，怎么同步：维护者更新仓库后，你的 fork 和本地都会落后。两步拉齐：
bash
git fetch upstream # 先把原作者的新提交下载到本地
git merge upstream/main # 再合并进你的 main
git push origin main # 最后推回你自己的 fork同步完再从最新 main 开新分支，下一个 PR 就不会和原作者的最新代码打架。
7. 规范化交付四件套
- README：回答五问------做什么、怎么开始、使用示例、出问题去哪求助、谁在维护。
- .gitignore ：忽略缓存/构建产物/本地配置（
.DS_Store、node_modules/、__pycache__/、.env）。 注意 ：.gitignore只能忽略未跟踪 的文件------如果某个文件已经 commit 过了 ，再加进.gitignore是无效的 ！必须先git rm -r --cached <文件或文件夹>让它停止跟踪。 团队场景 ：如果这个文件已经被队友 pull 到本地，你执行git rm并 push 后，队友下次 pull 会直接硬删除本地文件。团队公共文件动手前，先提醒队友备份或改名。 - License：公开 ≠ 开源。没有 License 时默认版权保留，别人不会自动获得复制、修改、分发许可。
- 安全扫描：发布前搜 API Key、Token、密码、私钥、个人邮箱、绝对路径；AI 生成的项目尤其要查。Token 走环境变量或 GitHub Secrets，别写进仓库再靠忽略补救。
Commit 信息按规范写（Conventional Commits） ：提交信息别只写「动作 + 对象」，进阶者按行业标准前缀写：
feat:新功能、fix:修复 Bug、docs:改文档、refactor:重构、chore:杂务。让 AI 帮写 Commit 时，也明确要求它按这个格式出。
8. 云端自动化：Actions、Pages、Release
- Actions ：
.github/workflows/下写工作流（比如check.yml用actions/checkout检查 README.md、index.html 是否存在）。失败就进日志看第一条真正失败的命令（exit code），修对应文件，别只会反复重新运行。 - Pages ：Settings → Pages → 从 main 根目录发布，静态页面获得公开网址（比如
https://<用户名>.github.io/<仓库>/）。适合静态站点，不能跑需要常驻服务/数据库的应用。 - Release ：打标签
v1.0.0+ 写版本说明，是作者交付正式版本的入口。
9. Git 翻车不慌：极速救急指南
五种翻车急救表：
| 现象 | 先查什么 | 第一处理动作 |
|---|---|---|
| Permission denied / 403 | 账号、仓库权限、远端地址、登录方式 | 确认身份与授权，别反复输密码 |
| push 被拒，远端有新提交 | 本地是否落后 | fetch → 看差异 → pull 后再 push |
| 合并冲突 | 哪些文件同一位置被两边修改 | 打开冲突文件，保留最终内容，删标记后重新提交；改乱了可 git merge --abort 一键回到合并前 |
| 文件过大 / 仓库变重 | 大文件类型 | 从提交移出，按用途选 Release 或 Git LFS |
| 密钥已推送 | 密钥是否还能用 | 立即撤销并轮换，再评估清理历史 |
| 网络连接失败（Proxy/Timeout） | 代理、梯子、网络连通性 | 先查网络与代理设置，这不是 Git 的锅 |
写挂了想回退：Reset 还是 Revert
git reset --hard抹一切 （毁尸灭迹，适合本地丢弃、未 push 的提交）。执行前先确认git status是 clean 的 ------未保存、未 add 的改动一旦被--hard覆盖，连 reflog 都救不回来（它们从没进过版本库）。git revert撤销并新发提交（保留历史，适合已 push 的公共分支，不破坏他人）。
reflog：本地的后悔药 。玩转reset --hard或分支强删后误删了代码？只要在本地提交过 ，git reflog就能看整台电脑的「后悔药日记」，找到被删提交的哈希值，一条命令直接拉回来。
遇到故障先保账号、凭据和远端历史；对强推、rebase、历史清理没把握就先备份。分支多一个、提交信息不漂亮都可以以后整理，密钥仍有效或远端可能被覆盖时，先停下普通操作。
结语
下次打开 GitHub，先问自己：是读项目 、拿文件 、保存修改 ，还是交付版本？看清眼前这一步，入口就不会乱。
附录｜术语清单
| 术语 | 一句话解释 |
|---|---|
| Git | 装在电脑上的版本管理工具，记录每次修改，支持回退，离线可用 |
| GitHub | 承载远端仓库的平台，提供 Issues、PR、Actions、Pages、Release 等能力 |
| Repository（repo/仓库） | 存放项目文件、说明、配置和完整提交历史的地方，不一定是程序 |
| Commit（提交） | 一次修改的存档，含改动内容、时间与提交者；每次只放一组相关修改 |
| Branch（分支） | 隔离一组未确认改动的工作线，默认分支通常叫 main |
| main | 仓库默认分支（GitHub 新仓默认），一般作为稳定主线；老项目或本地 git init 可能叫 master，两者只是默认名不同 |
| Tag（标签） | 给某个提交固定的名字，常用来标记 v1.0.0 版本 |
| README（README.md） | 项目说明书，写明用途、安装、用法、反馈入口 |
| Clone（克隆） | 把仓库连同版本历史完整复制到本地，适合长期跟踪和修改 |
| Fork（派生） | 在自己账号下复制一份别人的仓库副本，改完可向原作者发 PR |
| Issue | 记录问题、建议和待办，报错时写清系统、版本、步骤和报错 |
| Pull Request（PR） | 提交一组修改并请求合并，base/compare 分别指目标与来源分支 |
| Actions | 自动检查/测试/部署，绿勾通过、红叉看日志定位失败步骤 |
| Pages | 把仓库里的静态页面发布成公开网址 |
| Release | 作者正式交付的版本，在标签基础上附加说明和安装包 |
| License（许可） | 规定别人能否复制、修改、分发；没有 License 默认版权保留 |
| .gitignore | 忽略缓存、构建产物、本地配置等不该进版本历史的文件；只对未跟踪文件生效 |
| 工作区（working tree） | 你正在编辑的项目目录 |
| 暂存区 | git add 后放置待提交修改的地方 |
| status / add / commit / push | 查看变化 / 加入暂存 / 存为本地版本 / 同步到 GitHub |
| pull / fetch | 把远端新提交拿到本地；fetch 只下载不改动，pull = fetch + merge |
| origin / upstream | 常见远端别名：自己的远端 / 原作者仓库 |
| Diff | 查看文件改动对比，绿色为新增、红色为删除 |
| Merge（合并） | 把分支改动并入另一分支；同一位置被两边修改时产生冲突 |
| Rebase（变基） | 重新调整提交的基准，把分支历史变成一条没有分叉的直线，让历史更线性；改写过的提交不要强推 |
| 冲突（conflict） | Git 无法替你选择最终内容，需打开文件保留正确内容并删标记 |
| Force push（强推） | 覆盖远端历史，可能丢失现场，不了解差异时不要使用 |
| SSH / HTTPS / GitHub CLI | 三种连接认证方式，账号密码已不能直接当 Git 密码 |
| Stash（临时存单） | 把写一半的修改暂存起来，切分支修完 Bug 后 git stash pop 取回 |
| Reset | 回退提交；--hard 直接丢弃修改，适合本地未 push 的场景 |
| Revert | 撤销某次提交并新增一条反向提交，保留历史，适合已 push 的公共分支 |
| Reflog | 本地「后悔药日记」，可找回被 reset/删除的提交 |
| Conventional Commits | 提交信息规范前缀：feat: 新功能、fix: 修 Bug、docs: 文档 |
| Git LFS | 大文件存储方案，配合视频、模型、数据库等超大文件使用 |
| Secrets | GitHub 提供的密钥存储，用环境变量方式给流程注入凭据 |