GitHub 从零开始详细教程

Kelvin·约 22 分钟阅读

2026年9月30日9月30日

文章目录

写在前面：你不需要先学会编程

相信很多人第一次打开 GitHub，会看到一串英文、几十个文件夹、几个陌生按钮，然后直接关掉。

这很正常。GitHub 的界面本来就不是为第一次接触的人设计的。

你可以先把它理解成一个放在网上的项目文件夹。这个文件夹不只保存当前文件，还会记录：

文件改过什么；
哪一次修改是谁做的；
以前的版本是什么样；
别人遇到了什么问题；
作者有没有继续维护；
其他人能不能修改、复制或商用。

所以，GitHub 既像网盘，又不像普通网盘。它更像一个带历史记录、讨论区、协作工具和作品展示页的项目空间。

这篇教程面向完全不懂的小白。你不需要一开始就背命令，也不需要先学会写代码。读完后，你应该能做到：

看懂一个 GitHub 仓库大概是干什么的；
判断一个项目能不能直接安装，应该下载什么；
在网页上发布自己的文章、提示词、模板或作品；
看懂 Commit、History、Branch、Fork、Pull Request；
用最少的 Git 命令把电脑里的项目上传到 GitHub；
知道如何安全地使用陌生开源项目；
继续学习 Actions、Pages 和开源协作。

整篇只有一条主线：先会浏览和发布，再理解 Git，最后进入协作和自动化。

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

这是所有新手最容易混淆的地方。

Git 是什么

Git 是安装在你电脑上的版本管理工具。它负责记录项目在本地发生过的变化。你今天改了一版，明天又改了一版，Git 可以把这些版本保存下来。即使断网，你也能查看差异、找回旧版本，或者从当前项目分出一条新路线尝试功能。

Git 不等于 GitHub。你完全可以只在自己的电脑上使用 Git。

GitHub 是什么

GitHub 是一个在线平台，用来托管 Git 仓库。把项目放到 GitHub 后，你可以换一台电脑继续工作、和别人一起修改、接收问题反馈、发布软件版本、使用自动化测试和部署，也可以把作品当成公开作品集。

可以这样记：

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 让你安装 Python、Node.js、Docker，或者运行 pip、npm、docker 命令，说明它不是双击即用的软件。你可能还要安装依赖、配置环境变量、启动服务或申请第三方 API。

看不懂命令时，不要直接复制运行。先让 AI 解释每条命令、所需权限和可能改动的文件。

给 AI 的安全检查提示词

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

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

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

仓库链接：【粘贴链接】

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

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

不会写代码，也可以建立 GitHub 仓库。下面用提示词和工作模板仓库做例子，文章、清单、教程、研究笔记都可以照着做。

1. 新建仓库

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 文档格式。

正文可以放：

提交说明写：加入文章审稿提示词

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 为什么不是普通网盘

修改 prompts/article-review.md，在最后加上：

更新记录

2026-09-30：加入事实核查要求，避免 AI 自行补充数字和案例。

保存时提交说明写：

补充事实核查要求

打开这个文件，点击右上角 History。你会看到这个文件以前的提交记录。点开某次提交，就能看到那一次增加了什么、删除了什么。

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

Commit 怎么写

不推荐：

更新修改最新版 fix

更好：

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

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

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

这是整篇最不能省的一节。

Public 仓库里不要出现这些东西

API Key；
Personal Access Token；
Cookie；
密码；
钱包私钥和助记词；
数据库连接地址；
客户资料和内部文件；
私人照片；
手机号、住址和个人邮箱；
浏览器截图里的登录信息；
电脑用户名和本地路径；
.env 文件；
日志和调试输出。

.gitignore 是什么

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

.env node_modules/ .DS_Store *.log dist/

它告诉 Git：这些文件不要纳入版本管理。

但要记住：.gitignore 只对还没有被提交过的文件有效。如果密钥已经提交过，后来再加 .gitignore，历史里仍然可能有它。

如果密钥已经公开

正确顺序是：

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

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

公开前检查提示词

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

请检查：

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

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

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

AI 只能协助检查，不能给你绝对安全的保证。尤其要自己看旧版本、图片角落和没有被 AI 读取的文件。

八、Git 的四个基础概念

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

仓库 Repository

一个被 Git 管理的项目文件夹叫仓库。在本地项目目录运行：

git init

Git 会创建一个隐藏的 .git 目录，里面保存版本记录。不要随意删除 .git。删除它不会删除普通文件，但会让这个文件夹失去 Git 历史。

提交 Commit

Commit 是一次带说明的版本快照。

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

git status：看看哪些文件发生了变化；
git add：把准备保存的改动放进暂存区；
git commit：把暂存区内容保存成一个本地版本。

为什么 add 和 commit 要分两步？因为你可以只提交一部分改动。比如三个文件里只有一个已经完成，就只 git add 那一个。

分支 Branch

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

git switch -c try-category-filter

这条命令会新建分支并切换过去。做完测试后回到主分支：

git switch main git merge try-category-filter

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

远程 Remote

远程仓库就是 GitHub 上的仓库。通常把 GitHub 那个地址叫作 origin：

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

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

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

1. 安装 Git

macOS 可以安装命令行开发者工具：

xcode-select --install

也可以使用 Homebrew：

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：把改动记入本地 Git 历史；
Push：把本地 Commit 上传到 GitHub。

十、HTTPS、SSH Key 和 PAT 怎么选

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

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

生成密钥时，优先使用 ed25519：

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 只显示一次。生成后立刻复制到密码管理器。不要把 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 是什么

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 更适合看传播趋势，不适合单独作为质量证明。

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

如果你确实要看源码，目标不要定成读完整个项目。先只搞懂一个功能，或者只找到你要修改的那几百行。

五步阅读法

第一步：只读 README

先搞清楚它解决什么问题、如何启动、有没有 Quick Start、依赖哪些环境。

第二步：跑起来

静态读代码效率很低。能按照 README 启动，就先运行起来，点几下或调用一次接口，建立基本手感。

第三步：找程序入口

第四步：按功能走链路

比如看登录功能，就从登录入口一路跟下去：

页面按钮 → 路由 → 处理函数 → 数据库查询 → 返回结果

不要按文件夹从头读。按一个功能走通，项目骨架自然会出现。

第五步：看测试、提交和 Blame

测试文件经常是最准确的使用说明：参数怎么传、返回什么、边界在哪里，测试里通常写得很清楚。

GitHub 的 Blame 可以查看某一行是谁、什么时候、因为哪次提交写出来的。看不懂一段奇怪代码时，Blame 往往能告诉你它是临时方案、兼容逻辑还是历史遗留。

GitHub 网页阅读快捷键

你不一定要先 Clone，很多源码阅读任务在网页上就能完成。

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

Actions 是仓库自动化功能。你在 .github/workflows/ 下放一个 YAML 文件，GitHub 就能在推送、提 PR 或定时触发时执行任务。

最小示例：

它的意思是：每次推送到 main，GitHub 启动一台 Ubuntu 虚拟机，拉取代码、安装 Node、安装依赖并运行测试。

适合自动化的事情包括：每次推送跑测试、检查代码格式、打 Tag 时自动打包、自动发布 Release、定时运行任务和自动部署网站。

Actions 额度

额度和收费规则会变化。当前 GitHub 官方说明中，GitHub Free 个人账户对私有仓库包含每月 2,000 分钟 Actions 配额；公开仓库使用标准 GitHub-hosted runner 通常免费。Storage、缓存、超出配额和不同类型 Runner 可能另行计算，正式使用前看账户当前 Billing 页面。

不要把高频、长时间的任务随便放进私有仓库，也不要默认不同 Runner 的成本完全一样。

Actions 报错怎么读

不要只看最上面的：

Process completed with exit code 1

这只说明某条命令失败了，不是具体原因。进入那次运行，点左侧红色叉号的步骤，再往前翻日志。

本地能运行、Actions 失败的常见原因是本地有 .env、Runner 没有依赖、系统版本不同、环境变量没有配置，或者命令在本地和 CI 中行为不同。

需要密钥时，到仓库的 Settings → Secrets and variables → Actions 配置，再在 workflow 中使用：

${{ secrets.YOUR_SECRET_NAME }}

不要把密钥写在 YAML 文件里。

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

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

方法一：个人主页仓库

新建仓库时，名字写成：

你的用户名.github.io

放入 index.html 或 README 内容，再按仓库的 Settings → Pages 设置发布来源。网站地址通常是：

https://你的用户名.github.io

进入：

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 都可以进入。

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

把 .env 提交上去了

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

文件超过 GitHub 单文件限制

GitHub 普通仓库对单文件有大小限制。大文件可以考虑 Git LFS、Release 附件、专门的对象存储，或者不把构建产物和原始素材放入代码仓库。

查找仓库中较大的 Git 对象，可以使用：

提交邮箱和 GitHub 账号对不上

git config user.email

确认它和 GitHub 账号中可识别的邮箱一致。

在 main 上改崩了

如果只是未提交的改动，可以先暂存：

git stash git stash pop

如果只是想丢弃某个文件的未提交改动，现代 Git 可以用：

git restore 文件名

这会丢失该文件未提交的修改。git reset --hard 更危险，除非你确定不需要这些改动，否则不要随便执行。

Fork 之后原项目更新了

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

git push 被拒绝

常见原因是没有写入权限、远程地址指错、远程分支比本地更新、认证失败，或者分支受保护。

先运行：

git remote -v git branch --show-current git status

看清楚你在哪条分支、要推到哪个仓库，再决定下一步。

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

不要只说帮我上传到 GitHub。更安全的方式是分三步。

第一步：只检查，不修改

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

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

第二步：确认后提交

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

第三步：确认目标后 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 后，换平台主要是熟悉界面和权限规则，不需要从头学另一套版本管理。

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

你今天可以只做五件事：注册账号、建一个仓库、写一份 README、上传一个真正有用的文件、把链接发给一个人使用。

用网页完成这五步，你就已经跨过了最难的门槛。

接下来再慢慢理解：

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

真正有用的 GitHub，不是收藏了一堆链接，而是你能判断一个项目是否可靠，能把自己的成果整理成别人看得懂、拿得到、反馈得了的仓库。

等你第一次发布的作品被别人打开、使用并留下一个问题时，你才会真正理解：GitHub 不是放代码的网站，而是一套让作品继续生长的公开记录。

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

Star：收藏，不是质量认证

Star 更像收藏或关注。数量大只能说明项目传播广，不能证明代码质量高。判断项目时看趋势和最近维护，不要只看绝对数量。

Watch：接收项目动态

Watch 会把项目的新 Issue、PR 和其他动态推送给你。只对自己正在使用或准备参与的项目开启，别把所有仓库都 Watch，否则通知会变成噪音。

Fork：复制到自己的账号

Fork 会在你的账号下生成一份仓库副本，原项目不受影响。想给原项目贡献代码，通常就是 Fork 后在自己的副本上修改，再通过 PR 请求合并。

Issue：问题、需求和讨论

提 Issue 前先搜索是否有人提过相同问题。对新手来说，带有 good first issue 或 help wanted 标签的 Issue，往往是参与开源的入口。

Pull Request：请求合并修改

PR 不只是提交代码的地方，也是学习真实项目协作的地方。打开一个已经合并的 PR，查看 Files changed 和 Review，你能看到维护者关心什么、一次改动如何被讨论和修改。

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

GitHub 的免费计划和用量会变化，下面只记用途，具体额度以账户当前页面为准。

Copilot 等其他服务也可能有免费计划或试用额度，但具体权限和配额会变化，不要把宣传页面上的数字当成永久承诺。

官方参考

全文完