GitHub 从零开始详细教程：看懂仓库、发布作品、版本管理与开源协作

第一次打开 GitHub，大概率是一屏英文、几十个文件夹、几个不认识的按钮，然后默默关掉。这很正常——GitHub 的界面本来就不是为第一次用的人设计的。

但它其实没那么玄。你可以先把它理解成一个放在网上的项目文件夹。这个文件夹不只存当前的文件，还记得：文件改过什么、哪一次改动是谁做的、旧版本长什么样、别人遇到过什么问题、作者还在不在维护、其他人能不能改 / 复制 / 商用。所以它像网盘，又比网盘多出一整套历史记录、讨论区、协作工具和作品展示页。

这篇教程写给完全不懂的人。你不需要先背命令，也不必先会写代码。读完你应该能做到：看懂一个仓库大概在干什么；判断一个项目能不能直接装、该下哪个文件；在网页上发布自己的文章、提示词、模板或作品；看懂 Commit、History、Branch、Fork、Pull Request；用最少的 Git 命令把电脑里的项目传到 GitHub；知道怎么安全地碰陌生开源项目。全文只有一条主线：先会浏览和发布 → 再理解 Git → 最后进入协作与自动化。

一、先分清：Git 和 GitHub 不是一回事

这是新手最容易混的一点，先掰开说。

• Git：装在你电脑上的版本管理工具，负责记录本地项目的变化。今天改一版、明天再改一版，它都存着；就算断网，你也能查看差异、找回旧版本，或者拉一条新路线去尝试功能。你完全可以只用 Git，完全不上 GitHub。
• GitHub：托管 Git 仓库的在线平台。项目放上去之后，你可以换一台电脑接着干、和别人一起修改、接收问题反馈、发布软件版本、跑自动化测试和部署，也能把作品当成公开作品集。

一句话记牢：Git 是本地的记账本，GitHub 是网上的项目空间。

还有一点得纠正：GitHub 不只是程序员放代码的地方。文章、AI 提示词、Skills、工作流、模板、数据集、研究记录、设计素材、个人作品，都能放进去。

二、注册账号：这几项别随便填

打开 github.com，点右上角 Sign up。有几个地方值得认真点。

用户名要认真取

用户名会出现在你的个人主页和仓库地址里：https://github.com/你的用户名、https://github.com/你的用户名/仓库名。如果你打算把 GitHub 当作品集或公开名片，就别取太随意——网名、英文名或个人品牌名，通常比 xiaoming123456 更合适。

邮箱和两步验证

用你能长期访问、能正常收信的邮箱。注册后开启两步验证，优先用验证器 App。开启时 GitHub 一般会提供恢复码，存到密码管理器或其他安全位置，别只放在手机相册里。

Public 还是 Private

可见性	谁能看	适合放什么
Public	任何人	公开作品、开源项目、资料库
Private	只有你和被授权的人	未整理内容、私人材料、内部项目

要记住：仓库一旦公开，别人可能已经下载、Fork 或存了副本；之后再改成 Private，并不代表那些副本会自动消失。

三、第一次打开仓库，先看这五处

不用一上来就读代码。按下面的顺序看，通常几分钟就能判断一个项目值不值得继续。

1. README：它是干什么的

README 通常是仓库首页最重要的说明文件。先找这几件事：它解决什么问题、适合谁用、怎么安装和启动、有没有在线演示、有哪些已知限制、问题该去哪儿反馈。

2. Releases：有没有成品

如果这是一个软件，优先看 Releases。打开标着 Latest 的正式版本，再看 Assets，按你的系统和芯片选文件。如果 Assets 里只有 Source code (zip) 和 Source code (tar.gz)，通常说明作者只给了源码，没有可直接安装的成品。

3. Issues：别人遇到过什么问题

Issues 是项目的问题与讨论区。这里能看到安装失败、系统兼容、功能请求、隐私疑问，以及作者是否还在回复。判断一个项目「还活着吗」，不要只看 Star——一起看最近提交、最近 Release，以及 Issues 有没有人回。

4. LICENSE：能不能随便用

公开仓库不等于里面的东西都能拿去卖。LICENSE 是项目的使用规则，可能规定是否允许修改、分发、商用、署名或公开衍生作品。没有 LICENSE 时，默认版权规则依然存在——能看到公开内容，不等于自动拥有复制、修改、再发布和商业使用的权利。

5. Commit 和更新时间：项目还活着吗

Star 多，只能说明项目被很多人关注过，不能证明它现在仍在维护。更有用的判断是：最近一次提交、最近的 Release、Issues 是否有人回、新版本是否持续发布。

四、下载 GitHub 项目：先分清你拿到的是什么

绿色的 Code 按钮不是「下载并安装」。点开它之前，先分清你要的东西是哪一类。

你想要	怎么做	注意
安装某个软件	先看 README，再找 Releases，打开 Latest，在 Assets 里按系统选文件	只给源码的，多半要自己编译，不是双击即用
拿提示词 / 模板 / 文档 / 资料	Code → Download ZIP，解压后回 README，按说明复制或导入	照着 README 放对文件夹位置
拿到的是源码	README 里出现 Python / Node.js / Docker，或 pip / npm / docker 命令，就说明要自己配环境	可能要装依赖、配环境变量、启服务、申请 API

看不懂命令时，别直接复制运行。先让 AI 解释每条命令、所需权限、以及可能改动哪些文件。下面这段提示词可以直接抄。

先不要下载、安装或运行这个 GitHub 仓库里的任何内容。

请先阅读它的 README、Releases、LICENSE 和最近的 Issues，然后告诉我：
1. 它提供的是可直接使用的软件、资料包，还是只有源码？
2. 我的设备是【填写系统和芯片】，应该下载哪个具体文件？
3. 下载后怎样安装、打开或导入？
4. 需要安装哪些依赖、运行哪些命令、申请哪些权限？
5. 是否会读取本地文件、联网、上传数据或要求 Token、Cookie、管理员权限？
6. 最近是否有人反馈安装失败、恶意文件、停止维护或隐私问题？

证据不足的地方写「无法确认」，不要猜。
先列出检查结果和准备执行的步骤，等我确认后再下载或运行。

仓库链接：【粘贴链接】

AI 可以帮你读说明，但不能替你保证软件绝对安全。未知来源的脚本、压缩包和安装器，风险始终要自己判断。

五、在网页上发布你的第一个作品

不会写代码，也能建 GitHub 仓库。下面用「提示词 / 工作模板仓库」做例子，文章、清单、教程、研究笔记都照这个做。

1. 新建仓库

登录 GitHub，点 New repository，填：Repository name（例如 my-toolbox）、Description（一句话说明放什么）、Visibility（准备公开选 Public，没整理好选 Private）、勾上 Add a README file，然后 Create repository。你会得到 https://github.com/你的用户名/my-toolbox，README 会直接显示在仓库首页。

2. 写 README

点 README 右侧的铅笔图标，写一份最小说明；页面底部填提交说明（例如「建立工具箱首页」），点 Commit changes。这里的 Commit 可以先理解成「带说明的一次保存」。

3. 新建文件

回仓库首页，点 Add file → Create new file，文件名写成 prompts/article-review.md——斜杠前的 prompts 会变成文件夹，.md 是 Markdown 格式。正文放你的内容，提交说明写「加入文章审稿提示词」，再 Commit。

4. 给 README 加入口

把 README 补成带链接的目录，例如：

## 已发布

- [AI 文章审稿提示词](prompts/article-review.md)：检查理解障碍、逻辑跳跃、重复内容和待核查事实。

从仓库首页点这个链接，能进去，你就已经完整走了一遍：建仓库 → 写 README → 新建文件 → 整理目录 → 建立入口。

5. 上传现成文件

如果电脑里已经有文章、模板、清单或说明文档，点 Add file → Upload files，把文件拖进页面，填提交说明，再 Commit changes。内容多了可以按用途分目录：

my-toolbox/
├── README.md
├── prompts/       AI 提示词
├── templates/     文档和表格模板
├── examples/      使用示例
└── docs/          说明和教程

刚开始只有一两个文件时，不必提前设计复杂目录。先发布，再按真实内容整理。

六、Commit 和 History：GitHub 为什么不是普通网盘

改动一个文件，保存时提交说明写清楚，然后点开这个文件的 History，你就能看到它以前的每次提交；点开某一次，能看到那一次加了什么、删了什么。

你不需要再存一堆「最终版」「最终版 2」「真的最终版」。每次修改都有记录，什么时候改的、改了什么，都能查。

Commit 怎么写？别写「更新」「修改」「最新版」「fix」，改成能说清一件事的句子，例如：

• 增加文章事实核查要求
• 修复 README 中的失效链接
• 增加 Windows 安装说明

一条 Commit 尽量只做一件事，别把改样式、加功能、升级依赖和改文档全混在一次提交里。

七、公开发布前的安全检查

这是整篇最不能省的一节。公开仓库里，下面这些都不应该出现。

类别	具体例子
凭据类	API Key、Personal Access Token、Cookie、密码、钱包私钥与助记词、数据库连接地址
隐私类	客户资料与内部文件、私人照片、手机号、住址、个人邮箱
环境类	.env 文件、日志与调试输出、浏览器截图里的登录信息
本地信息	电脑用户名、本地路径、浏览器账号与通知内容

.gitignore 是什么

之后如果你用 Git 管理本地项目，可以在项目根目录建一个 .gitignore：

.env
node_modules/
.DS_Store
*.log
dist/

它告诉 Git：这些文件不要纳入版本管理。但有个坑——.gitignore 只对「还没被提交过」的文件有效。如果密钥已经提交过，后来再加 .gitignore，历史里仍然可能有它。

如果密钥已经公开了

1. 立刻去对应平台作废或轮换密钥；
2. 生成新密钥；
3. 从当前文件里删除敏感信息；
4. 再考虑清理 Git 历史；
5. 检查是否已经被别人 Fork、下载或缓存。

只删当前文件不够。旧 Commit、别人存的副本、搜索缓存里，都可能还留着原内容。

公开前检查提示词

我要把一个 GitHub 仓库分享给别人。请做一次公开前安全检查。

请检查：
1. 文件名、README、正文、示例配置、日志和截图中是否有 API Key、Token、Cookie、密码、私钥、助记词或数据库连接信息；
2. 是否有客户资料、内部链接、真实姓名、手机号、邮箱、住址和私人照片；
3. 是否有电脑用户名、本地路径、浏览器账号和通知内容；
4. 是否有 .env、配置文件、日志或 AI 对话记录等不该公开的内容；
5. 仓库是 Public 还是 Private；
6. LICENSE 是否允许我想做的复制、修改、分发或商用行为。

不要完整复述疑似敏感内容，只保留少量首尾字符，中间用 *** 遮住。
用表格输出：位置｜发现的问题｜风险原因｜建议处理方式。
没有实际看到的文件不要判断为安全，统一标为「需要人工确认」。

最后只给一个结论：可以分享、修改后再分享、暂时不要分享。

AI 只能协助检查，给不了绝对安全的保证。旧版本、图片角落、AI 没读到的文件，还是得自己看一遍。

八、Git 的四个基础概念

现在开始接触 Git。先只记四个词：仓库、提交、分支、远程。

1. 仓库 Repository

一个被 Git 管理的项目文件夹就是仓库。在本地项目目录运行 git init，Git 会创建一个隐藏的 .git 目录，版本记录都在里面。不要随意删 .git——删它不会删掉普通文件，但会让这个文件夹失去全部 Git 历史。

2. 提交 Commit

git status
git add index.html
git commit -m "保存网页初始版本"

git status 看哪些文件变了；git add 把准备保存的改动放进暂存区；git commit 把暂存区内容存成一个本地版本。为什么 add 和 commit 要分两步？因为你可以只提交一部分改动——三个文件里只有一个做完了，就只 git add 那一个。

3. 分支 Branch

分支是一条独立的修改路线。可以把 main 想成当前稳定版，把新分支想成实验稿；实验失败，稳定版不受影响。

git switch -c try-category-filter
# 做完测试后回到主分支
git switch main
git merge try-category-filter

分支不是把整个文件夹复制一份，它更像指向某个版本的指针，所以创建分支很快。

4. 远程 Remote

远程仓库就是 GitHub 上的那个仓库，通常叫 origin：

git remote add origin https://github.com/你的用户名/仓库名.git
git push -u origin main

origin 只是约定俗成的名字，不是特殊关键字。同一个本地仓库也可以连多个远程，比如把原项目叫 upstream。

九、最少量 Git 操作：把本地项目上传到 GitHub

1. 安装 Git

macOS 可以装命令行开发者工具，或用 Homebrew：

xcode-select --install
# 或
brew install git

Windows 到 Git for Windows 下载安装，默认选项通常够用。装完验证：git --version。

2. 配置提交身份

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

这不是登录 GitHub，而是告诉 Git：以后提交记录显示谁的名字和邮箱。邮箱最好和 GitHub 账号里可识别的邮箱一致，或使用 GitHub 提供的隐私邮箱。查看配置用 git config --list。

3. 让 Git 接管项目文件夹

cd 你的项目目录
git init
git status
git add .
git commit -m "保存项目初始版本"

对陌生项目或含隐私的项目，不建议盲目 git add .，先看 git status 确认要提交什么。

4. 连接 GitHub 仓库

先在 GitHub 建一个空仓库。若本地已经有项目，创建时不要再自动添加 README，避免第一次同步出现不必要的冲突。然后：

git branch -M main
git remote add origin https://github.com/你的用户名/仓库名.git
git push -u origin main

第一次 Push 可能弹出登录或授权流程。以后提交完，通常只要 git push。

日常三步：

git status
git add .
git commit -m "说明这次改了什么"
git push

注意：保存文件、Commit、Push 是三个不同动作——保存是编辑器把内容写到电脑；Commit 是把改动记入本地历史；Push 是把本地提交上传到 GitHub。

十、HTTPS、SSH Key 和 PAT 怎么选

初学者可以先用 GitHub 网页完成发布；需要在本地反复 Push 时，再配置认证。

SSH Key：适合长期在本机使用

ssh-keygen -t ed25519 -C "你的邮箱"

公钥一般在 ~/.ssh/id_ed25519.pub。复制公钥内容，到 GitHub 的 Settings → SSH and GPG keys → New SSH key 粘贴，然后验证 ssh -T git@github.com。远程地址可改成 SSH 形式：

git remote set-url origin git@github.com:你的用户名/仓库名.git

SSH 私钥只留在自己电脑上，绝不要上传或发给别人。

PAT：适合脚本、API 和需要随时吊销的访问

GitHub 已不支持用账号密码直接做普通 Git 推送。Personal Access Token（PAT）可以理解成一把可设权限和有效期的钥匙，创建位置通常在 Settings → Developer settings → Personal access tokens。Token 只显示一次，生成后立刻存进密码管理器；不要写进仓库文件、截图、聊天记录或远程 URL。

你的情况	建议
只想在网页上发布	不用先学 SSH 和 PAT
在自己电脑长期推送	SSH 通常更省心
API、脚本、CI	用权限受限、有有效期的 Token
共享电脑	不要让系统长期记住凭据

十一、换电脑时用 clone 和 pull

clone：第一次把项目拿到新电脑

git clone https://github.com/你的用户名/仓库名.git
cd 仓库名

clone 会复制项目文件和已有提交，已经 clone 出来的项目不需要再 git init。只是临时阅读源码、不打算提交，可以用浅克隆：

git clone --depth 1 https://github.com/作者/项目名.git

准备提 PR 时不要依赖浅克隆，后续同步历史可能不完整。

pull：把 GitHub 上的新变化拉回来

git status
git pull

如果本地还有做到一半的修改，先处理完再 pull。如果 Push 被拒，不要第一反应就强制覆盖远程，先确认 GitHub 上多了哪些提交。

十二、分支：这次修改没把握，就别直接动 main

如果当前 main 是一个确认能用的版本，准备试新功能时，先开分支：

git status
git switch -c feat/category-filter

在分支里改、测、提交。确认没问题后：

git switch main
git merge feat/category-filter

测试没过就先别合并。切换分支前先看 git status。

Merge 和 Rebase

• merge：保留「分支合并发生过」的事实，适合公共分支和初学者；
• rebase：把提交重新接到另一条分支后面，历史更直，但会重写提交历史。

刚开始优先用 merge。不要在已经和别人共享的分支上随意 rebase 或强制 Push。

十三、Fork 和 Pull Request：参与别人的项目

Fork 和 Clone 的区别

• Fork：在 GitHub 上把别人的仓库复制到你的账号；
• Clone：把某个 GitHub 仓库下载到你的电脑。

通常的顺序是：先 Fork，再 Clone 你自己的那份 Fork。

修改别人项目的完整流程

# 先在原仓库首页点 Fork → Create fork，然后克隆你账号下的仓库
git clone https://github.com/你的用户名/项目名.git
cd 项目名
git switch -c docs/fix-dead-link
# 修改、测试并提交
git add .
git commit -m "修正文档中的失效链接"
git push origin docs/fix-dead-link

回到 GitHub，点 Compare & pull request，向原项目提交 Pull Request。

Pull Request 是什么

PR 可以理解成一句话：「我在自己的分支改好了，请你看看愿不愿意合并进项目。」 新手可以从修错别字、修死链、补文档、加简单示例开始。PR 描述说清三件事就够：

## 改了什么

修正 README 中指向旧页面的链接。

## 为什么

原链接已经 404，读者无法打开。

## 怎么验证

点击新链接可以正常打开。

如果 PR 对应某个 Issue，可以写 Closes #123。维护者让你修改时，继续在原来的分支上改，然后再次 Commit 和 Push，原 PR 会自动更新——不要重新开一个 PR。

让 PR 更容易被合并

• 一个 PR 只做一件事；
• 提交前阅读 CONTRIBUTING.md；
• 不要顺手重构无关代码；
• 先搜有没有人提过相同的 Issue；
• 维护者没及时回复时，不要连续催促。

十四、Issues：把「不能用」变成「能解决」

别人遇到问题来提问时，应该告诉你：用的是哪个文件或版本、什么系统 / 软件 / AI、具体做了哪些步骤、原本希望得到什么、实际发生了什么、是否已经删掉个人信息。你可以在仓库里放一个问题模板，路径是 .github/ISSUE_TEMPLATE/problem-report.md。

一个好的 Issue 不只是方便作者，也是在帮提问的人自己把问题理清。

十五、怎么搜索 GitHub 上的工具和资料

别只在搜索框输一个词然后盲翻。用限定符能精准很多。例如想找「最近还在维护、用 Go 写的自建聊天室」：

chat language:go stars:>100 pushed:>2026-01-01

想找整理好的资源清单：

awesome AI tools
topic:awesome
topic:self-hosted

搜仓库和搜代码不是一回事。结果页可以切到 Code，这时搜的是代码本身，例如 cloudflared language:yaml，你能看到别人真实用过的配置（代码搜索通常要登录 GitHub）。

看搜索结果别只看 Star。打开三到五个候选，依次看：README 讲清楚用途没有、Releases 有没有适合你设备的成品、最近有没有更新、Issues 是否集中出现同类报错、LICENSE 是否允许你的用法。Star 更适合看传播趋势，不适合单独当作质量证明。

十六、读陌生源码：不要从第一行读到最后一行

如果你确实要看源码，目标别定成「读完整个项目」。先只搞懂一个功能，或只找到你要改的那几百行。五步阅读法：

1. 只读 README：搞清楚它解决什么问题、怎么启动、有没有 Quick Start、依赖什么环境。
2. 跑起来：静态读代码效率很低。能按 README 启动就先跑起来，点几下或调一次接口，建立手感。
3. 找程序入口：定位启动文件与主流程。
4. 按功能走链路：比如看登录，就按「页面按钮 → 路由 → 处理函数 → 数据库查询 → 返回结果」一路跟下去。不要按文件夹从头读，按一个功能走通，项目骨架自然浮现。
5. 看测试、提交和 Blame：测试文件常是最准确的使用说明；Blame 能看某一行是谁、什么时候、因哪次提交写出来的，看懂一段怪代码往往靠它。

十七、GitHub Actions：让机器人自动做事

Actions 是仓库的自动化功能。你在 .github/workflows/ 下放一个 YAML 文件，GitHub 就能在推送、提 PR 或定时触发时执行任务。适合自动化的事包括：每次推送跑测试、检查代码格式、打 Tag 时自动打包、自动发布 Release、定时任务、自动部署网站。

Actions 额度

额度和收费规则会变，以官方当前说明为准。就目前 GitHub 官方说明：GitHub Free 个人账户对私有仓库包含每月 2,000 分钟 Actions 配额；公开仓库使用标准 GitHub-hosted runner 通常免费。存储、缓存、超配额和不同类型的 Runner 可能另行计费，正式用之前看账户当前 Billing 页面。不要把高频、长时间的任务随便塞进私有仓库。

Actions 报错怎么读

别只看最上面那句 Process completed with exit code 1——它只说明某条命令失败了，不是原因。进那次运行，点左侧红叉的步骤，再往前翻日志。「本地能跑、Actions 挂」常见原因是：本地有 .env、Runner 没装依赖、系统版本不同、环境变量没配、命令在本地和 CI 里行为不同。需要密钥时，到 Settings → Secrets and variables → Actions 配置，在 workflow 里用 ${{ secrets.YOUR_SECRET_NAME }} 引用，不要把密钥写进 YAML。

十八、GitHub Pages：免费发布一个网站

Pages 能把仓库里的静态内容发布成网站，适合个人主页、项目文档、简单博客、作品集和产品介绍页。

方法一：个人主页仓库

新建仓库时名字写成 你的用户名.github.io，放入 index.html 或 README，再在 Settings → Pages 里设置发布来源，网站地址通常是 https://你的用户名.github.io。

方法二：给已有仓库开 Pages

进 Settings → Pages → Build and deployment，选择从某个分支发布（例如 main），再选根目录 /root 或 /docs。

方法三：用 Actions 构建和发布

如果用 Hexo、Hugo、Jekyll、VitePress 这类需要构建的工具，可以让 Actions 先生成网站，再把产物发布到 Pages。

Pages 的几个坑

• 页面公开后，仓库里的静态文件也可能被直接访问，别放 API Key；
• GitHub Free 对个人账户的 Pages 权限以官方当前计划为准，公开仓库通常最稳妥；
• 第一次发布可能需要几分钟，别改一次就狂刷几十次；
• 用自定义域名，还要在域名服务商处加 DNS 记录，HTTPS 证书签发和 DNS 生效都可能要等；
• 国内访问速度可能不稳定，面向国内用户时要评估网络情况。

十九、把 GitHub 主页变成简历

创建一个与用户名完全相同的仓库（用户名是 kelvin，仓库名就叫 kelvin），在根目录放一个 README.md，它会显示在个人主页顶部。写法上，少写「热爱技术、拥抱变化」这种无法验证的话，多写：正在做什么、已经发布了什么、别人可以点开看什么。半年检查一次主页，过时的「正在做」比空白更尴尬。

二十、多人协作：两个人以上就要有规则

在仓库的 Settings → Rules / Branches 里给 main 设置规则：禁止直接 Push；必须通过 Pull Request；至少一名成员 Review；禁止强制 Push；限制删除分支。规则名称和界面会随 GitHub 更新变化，看到 Branch protection rules 或 Rulesets 都可以进去。

二十一、常见问题和处理方式

1. 把 .env 提交上去了

先作废其中的密钥，再清理仓库和历史。不要只删除当前文件。

2. 文件超过 GitHub 单文件限制

大文件可以考虑 Git LFS、Release 附件、专门的对象存储，或者干脆不把构建产物和原始素材放进代码仓库。

3. 提交邮箱和 GitHub 账号对不上

运行 git config user.email 确认，和 GitHub 账号里可识别的邮箱保持一致。

4. 在 main 上改崩了

git stash        # 暂存未提交改动
git stash pop    # 需要时再取回
git restore 文件名   # 丢弃某个文件的未提交改动（会丢失改动）

git reset --hard 更危险，不确定后果时别执行。

5. Fork 之后原项目更新了

git remote add upstream https://github.com/原作者/项目名.git
git fetch upstream
git switch main
git merge upstream/main
git push origin main

6. git push 被拒绝

常见原因：没有写入权限、远程地址指错、远程分支比本地新、认证失败、分支受保护。先运行 git remote -v、git branch --show-current、git status，看清你在哪条分支、要推到哪个仓库，再决定下一步。

二十二、让 AI 帮你操作 Git：先检查，后执行

不要只说「帮我上传到 GitHub」。更安全的做法是分三步。

第一步：只检查，不修改

检查这个项目当前有哪些修改。只查看，不要改文件、提交或上传。

告诉我：
1. 当前在哪条分支；
2. 修改了哪些文件；
3. 每个文件改了什么；
4. 是否含有密码、Token、Cookie、个人资料或其他不该公开的内容；
5. 当前远程仓库地址和目标分支是什么。

第二步：确认后提交

把刚才确认过的修改提交到当前分支。
先列出准备提交的文件和提交说明，等我确认后再执行。
暂时不要上传。

第三步：确认目标后 Push

告诉我这次会上传到哪个 GitHub 仓库和哪条分支。
检查远程地址、当前分支和待上传提交，等我确认后再执行 git push。

凡是涉及删除、强制覆盖、修改历史、写入 Token 的操作，都应该让 AI 先解释影响，不要让它无条件执行。

二十三、每天真正会用到的速查表

# 查看状态
git status
git diff
git log --oneline -10

# 提交和上传
git add .
git commit -m "说明改了什么"
git push

# 分支
git branch
git switch -c 新分支名
git switch 分支名
git merge 分支名

# 获取项目
git clone 地址
git pull

# 查看远程
git remote -v

# 暂存未完成的修改
git stash
git stash pop

# Fork 项目同步原仓库
git fetch upstream
git merge upstream/main
git push origin main

不知道下一步做什么时，先运行 git status。

二十四、Git、SVN、GitHub、GitLab、Gitee 的区别

GitHub、GitLab、Gitee 底层都可以用 Git。学会 Git 之后，换平台主要是熟悉界面和权限规则，不需要从头学另一套版本管理。SVN 则是更早一代的集中式版本管理，和 Git 的分布式模型不是一个思路。

结语：GitHub 不需要学完才能开始用

你今天可以只做五件事：注册账号、建一个仓库、写一份 README、上传一个真正有用的文件、把链接发给一个人使用。用网页完成这五步，你就已经跨过了最难的门槛。

接下来再慢慢理解：Git 在本地记录版本；GitHub 在线保存和协作；Commit 是一次有说明的版本快照；Branch 是一条独立修改路线；Fork 是把别人的仓库复制到自己账号；Clone 是把仓库下载到电脑；Pull 是把远程变化拉回来；Push 是把本地提交上传；PR 是请求原作者合并你的修改。

真正有用的 GitHub，不是收藏了一堆链接，而是你能判断一个项目是否可靠，能把自己的成果整理成别人看得懂、拿得到、反馈得了的仓库。等你第一次发布的作品被别人打开、使用、并留下一个问题时，你才会真正明白：GitHub 不是一个放代码的网站，而是一套让作品继续生长的公开记录。

附录 A：看懂仓库页面上的几个按钮

• Star：收藏，不是质量认证。数量大只说明传播广。判断项目看趋势和最近维护，别只看绝对数量。
• Watch：接收项目动态（新 Issue、PR 等）。只对自己在用或准备参与的项目开启，否则通知会变噪音。
• Fork：在你的账号下生成一份副本，原项目不受影响。想给原项目贡献代码，通常就是 Fork 后在自己副本上改，再通过 PR 请求合并。
• Issue：问题、需求和讨论。提之前先搜有没有人提过。带 good first issue 或 help wanted 标签的 Issue，往往是参与开源的入口。
• Pull Request：请求合并修改。打开一个已合并的 PR，看 Files changed 和 Review，你能看到维护者关心什么、一次改动如何被讨论和修改。

附录 B：GitHub 上常见的免费能力

GitHub 的免费计划和用量会变，下面只记用途，具体额度以账户当前页面为准。Copilot 等其他服务也可能有免费计划或试用额度，但权限和配额同样会变，不要把宣传页上的数字当成永久承诺。

官方参考：GitHub 仓库快速入门、GitHub 许可证说明、GitHub Actions 用量说明、GitHub Pages 快速入门、Git 官方安装页面。

相关阅读

• Douyin TikTok Download API：自托管抖音 / TikTok 数据采集与无水印下载 API（一个典型的 GitHub 开源项目）
• Free Claude Code（FCC）：聚合 56 个免费提供商、支持 11 种编码代理