很多人学 GitHub 的问题，不是教程看得少，而是一直停在“再看一篇”的状态。
你打开 GitHub，看见仓库、分支、commit、Pull Request，一下子觉得这像程序员的专业世界。于是开始收藏命令表，收藏开源项目，收藏“从入门到精通”。
但真正让你入门的动作很小：
建一个带 README 的仓库，改一行说明，再把它推回 GitHub。
这篇文章不讲开源文化大道理，也不讲大型团队协作规范。目标只有一个：让你今天跑通一次 clone -> add -> commit -> push。
先把目标缩小：今天只改 README
GitHub 新手最容易做反的一件事，是先背命令。
命令当然要会，但命令必须放在一个真实项目里才有意义。对 0 基础的人来说，最合适的第一个项目不是写代码，而是改 README。
README 是一个仓库的说明书。别人打开你的项目，第一眼通常不是看代码，而是看 README：
- 这个项目做什么；
- 现在能不能运行；
- 怎么安装；
- 怎么使用；
- 后续还准备补什么。
对 AI 从业者、产品经理、运营人和内容创作者来说，这不是程序员专属技能。你以后整理 Prompt、维护作品集、交付自动化脚本、和技术同事协作，都会遇到仓库、README、提交记录和 PR。
所以第一步别贪多。
今天只完成一个结果：让 GitHub 网页上的 README 真的因为你本地的一次修改而变化。
先分清 Git 和 GitHub
Git 和 GitHub 不是一回事。
Git 是你电脑上的版本管理工具。你可以把它理解成项目的存档系统：每改到一个阶段，就存一次档，以后能回看这次改了什么。
GitHub 是云端平台。它帮你托管仓库，也让别人能看到、评论、协作、提交 Pull Request。
一句话：
- Git 负责在你电脑上记录变化。
- GitHub 负责把这些变化放到云端，并让协作发生。
先记住这个关系就够了：
本地用 Git 做存档，云端用 GitHub 做同步和协作。
从 0 到 1 的正确顺序
1. 注册 GitHub 账号
打开 GitHub，创建个人账号，完成邮箱验证。
用户名别随手取，因为它会出现在你的仓库地址、个人主页和协作记录里。新手建议用稳定、短一点、全小写英文或英文加连字符的名字。
它不是昵称，更像你的公开工作身份。
2. 安装 Git
GitHub 网站只是云端，你电脑上还需要 Git。
安装完成后，在终端里输入：
git --version
看到版本号，说明本地工具已经可用。
3. 配置提交身份
第一次用 Git，要告诉它“这次提交是谁做的”。
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
再检查一次：
git config --global --list
这里的名字和邮箱会写进未来的提交记录。它不是社交简介，是版本历史里的署名。
4. 创建第一个 Repository
Repository 就是仓库，也可以先理解成一个带历史记录的项目文件夹。
第一步建议不要做复杂项目。只建一个练习仓库，例如：
my-first-github-note
创建时勾选 README，让仓库一开始就有一个说明文件。
这个文件就是你今天要改的第一个目标。
5. 把仓库 clone 到本地
在 GitHub 仓库页找到绿色的 Code 入口，复制仓库地址，然后在终端里执行：
git clone 仓库地址
这一步的意思是：把云端仓库复制到你的电脑上。
进入项目目录后，你就可以修改 README。
6. 记住日常四步：status、add、commit、push
改完文件，不等于 Git 已经保存。
Git 的日常循环是这四步：
git status
git add .
git commit -m "更新 README"
git push
每一步都有明确含义：
git status：先看当前改了哪些文件。git add .：把当前改动放进暂存区。git commit -m "..."：把暂存区变成一次存档。git push：把本地存档推到 GitHub 云端。
新手最容易漏的是 git add . 后面的点。这个点表示当前目录下的改动。没有它，很多文件不会进入这次提交。
commit message 也别写“改了一下”。写清楚结果，例如：
更新 README 的安装步骤补充项目截图说明修复示例命令错误
以后回看历史，这些句子就是你的项目时间线。
7. 用 Branch 保护主线
分支是 GitHub 协作里非常关键的一步。
你可以把主分支当成稳定版本，把新分支当成试验区。
想改 README，又怕改坏主线，可以这样：
git checkout -b update-readme
这会创建并切换到一个新分支。你在这个分支上修改、提交、推送，不会直接影响主分支。
8. 用 Pull Request 请求审查
Pull Request，简称 PR，可以理解成一句话：
我改了一些东西，请你看一下，没问题再合并。
典型流程是：
- 从主分支开一个新分支。
- 在新分支上修改文件。
- 提交并 push 到 GitHub。
- 在 GitHub 页面创建 PR。
- 审查通过后再合并。
对新手来说，PR 最大的价值不是“显得专业”，而是把修改和讨论放在一个清晰的位置。
别人能看到你改了什么，也能指出哪里不应该合并。
使用别人的仓库，先读 README
看到一个项目，不要先急着 clone。
先按这个顺序看：
- README：项目做什么、怎么安装、怎么运行。
- 文件列表：有没有你需要的源码、文档、示例。
- 提交历史：最近是否还在维护。
- Issues 和 PR：别人遇到什么问题，作者是否回应。
- License：是否允许你使用、修改或商用。
Stars 可以作为热度信号，但不能当成质量保证。
真正决定你能不能用的，是 README 是否清楚、最近是否维护、问题是否有人处理。
如果你想参与修改，通常要 fork 到自己账号，再 clone 到本地，开分支修改，最后发 PR 给原项目。
新手命令速查
先记这组就够用：
git --version
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git clone 仓库地址
git status
git add .
git commit -m "这次改了什么"
git push
git checkout -b 新分支名
不要一开始就学 rebase、reset、stash。
先把第一个 README 项目跑通，再学复杂操作。
今天的最小练习任务
如果你今天只做一件事，就做这个：
- 注册 GitHub 并完成邮箱验证。
- 安装 Git，确认
git --version能输出版本号。 - 创建一个公开练习仓库，勾选 README。
- clone 到本地。
- 修改 README，写下这个仓库准备用来记录什么。
- 执行
git status、git add .、git commit -m "更新 README"、git push。 - 回到 GitHub 页面刷新，确认 README 真的变了。
这一步完成，你就不是“看过 GitHub 教程”的人，而是已经有了第一个仓库闭环的人。
后面再学分支、PR、fork、协作规范和开源项目阅读，都会轻很多。
参考来源
- GitHub Docs: Creating an account on GitHub
- GitHub Docs: Set up Git
- GitHub Docs: Hello World
- GitHub Docs: Creating a pull request
- Pro Git: Git Basics and Git Branching