把代码修改变成可追踪的协作
代码版本越改越乱？用 GitHub 给每次修改留一条清晰路径。
GitHub 以仓库保存项目，用提交记录变更，再通过分支与 Pull Request 讨论修改。第一次上手，可以只用浏览器走完“新建仓库 → 改 README → 发起 PR”这条最小路径。
GitHub 的核心用途
GitHub 的仓库用于保存代码及相关文件；分支让修改与主线分开；Pull Request 让团队在合并前审查和讨论。GitHub 2025 年官方报告称平台有超过 1.8 亿开发者，这是当时的平台用户口径，不是本站排名。 使用时请以 GitHub 官网 ↗及官方帮助为准。
下方流程卡由本站绘制，不是 GitHub 的操作截图；实际按钮、权限与计划可能变化。
任务 01 · 保存项目
建一个仓库，先把项目目的写明白
仓库不只是文件夹。README 能让别人知道项目是做什么、如何运行，以及在哪里提问题。
仓库代码和项目文件
README用途与上手说明
可见性公开或私有
- 登录 GitHub，从新建仓库入口输入名称与简短说明。
- 选择公开或私有；含敏感代码或尚未公开资料的项目先考虑私有。
- 按需初始化 README，写最短的项目介绍和运行说明。
不要提交密钥。
查看官方仓库快速入门 ↗仓库即使设为私有，密码和访问令牌也不应写入代码或 README。
任务 02 · 安全修改
从主线开一条分支，再提交你的修改
假设要给 README 加使用步骤。先在新分支做变更，提交时写清做了什么，就能与现有版本区分。
主线当前稳定版本
新分支独立修改 README
提交留下变更记录
- 在仓库创建新分支，用能说明目的的名字，如 docs/getting-started。
- 编辑 README 或其他文件，检查变更范围只包含这次任务。
- 提交修改，提交说明写结果，例如“补充本地运行说明”。
提交前看差异。
查看 GitHub Hello World ↗意外加入的大文件、个人信息或配置文件，应该先排除。
任务 03 · 审查与合并
发起 Pull Request，让修改有理由、有讨论
PR 把新分支和目标分支的差异摆在一起，供自己或同事检查；确认无误再合并。
发起 PR说明改动和原因
审查查看差异与反馈
合并进入目标分支
- 从新分支发起 Pull Request，填写简洁标题和改动说明。
- 查看 Files changed，确认没有意外文件；按需请同事审查。
- 修正反馈并通过项目要求的检查后合并；团队可能设置额外审批或自动检查。
合并不是发布。
查看官方 Pull Request 入门 ↗代码进入主分支后是否上线，取决于项目自己的部署流程。
从一个具体任务开始。
选择 GitHub 是因为其官方报告显示广泛开发者使用。本页按官方 Hello World 与仓库文档整理，非 GitHub 官方教程；界面、权限及仓库规则以官网为准。