Git 和 GitHub 配合使用快速上手

0030 秒速览：三句话 + 一张处境表

读完这一篇，你能独立做完一件事：在自己电脑上建一个项目文件夹，让它记住每一次改动、随时能翻回任意一个版本，再把它推到 GitHub 上备份、分享、和别人一起改。全程照着命令敲即可，不需要先会编程。

先看几个数字，有个量级概念

如果你只有一个下午，按这个顺序走

按你现在的处境，直接跳到这一节

01Git 和 GitHub 到底是什么关系？

一句话：Git 是装在你电脑上的版本管理工具——"版本管理"就是替你记录一个文件夹里每一次改动，让你随时能翻回任意一个版本；GitHub 是托管这些记录的网站——把 Git 管的文件夹放到云端，方便备份、分享和多人协作。你在自己电脑上用 Git 干活，再决定要不要把成果推到 GitHub。

它不是什么（先破三个最容易搞混的理解）

先认识五个词，后面就不用猜了

它是什么（两句官方定义）

Git 官网对它的定义是：free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency。翻译成日常话：它是免费开源、每个人电脑上都有一份完整历史的版本管理工具——"分布式"这个词的意思是，每个克隆下来的人都拿到一份完整仓库，不是只有一个中央服务器说了算。

GitHub 官方文档说：At the heart of GitHub is an open-source version control system (VCS) called Git.——这里 VCS 是"版本控制系统"的英文缩写，整句的意思是：GitHub 的核心就是一个叫 Git 的开源版本控制系统，它负责把本地成果托管、展示出来，并加上评审、议题、自动化这些协作功能。

Git 在本地到底存了什么？

一个 Git 项目就是你的项目文件夹 + 顶层一个隐藏的 .git 文件夹。.git 就是它的"大脑"，里面装着项目的完整历史、一份"当前文件清单"（官方叫 index，索引），以及指向历史各个节点的分支指针。你不用去读它，但要知道两件事：删掉 .git，这个文件夹就退化成普通文件夹，历史全没了；拷贝整个文件夹（含 .git）就等于拷贝了全部历史。

历史是由三种"积木"搭起来的：文件内容块（某个文件在某一刻写了什么）、目录结构块（哪个文件夹里放着哪些文件）、提交（指向一份目录结构，并指向它的上一个提交——无数个提交串成一条链，就是历史长河）。所以"提交"不等于"保存文件"，而是给整个项目拍一张带备注的照片，照片按时间串成链。

一次改动要走过哪三个区？

02为什么不用"压缩包 + 网盘"？

如果你只是一个人写点小脚本，Git 最直接的价值是"后悔药"；一旦这件事要备份、分享、找人帮忙、长期维护，Git + GitHub 就变成标配。先看你熟悉的老办法能撑到哪一步。

"每天存一个压缩包"到底哪里不够用

没有 Git 的四个真实困境

GitHub 额外给了什么（Git 本地做不到的）

什么时候其实不需要它

诚实一点：Git 不是所有场景都值得用。下面这些情况，用更简单的工具反而更省事——但只要你开始改代码并想留住每一次变化，它立刻变得划算。

03怎么在 Mac 上装好，并让 GitHub 认得你？

目标：让你的电脑能跑 git 命令，并且 GitHub 知道"这次提交是你做的"。按顺序做完大约 15 分钟，全程不需要管理员权限（也就是不用加 sudo）。

开始前：先打开"终端"

按 Command + 空格，输入"终端"（英文是 Terminal），回车，会弹出一个黑窗口。下面所有命令都在这个窗口里逐行粘贴执行：看到输出符合预期，再贴下一行。

第 1 步：装上 Git（macOS 优先用 brew）

先看系统里是不是已经有了：

git --version
# 有输出如 git version 2.4x 就说明已安装，可跳到第 2 步

如果提示"找不到命令"，用 brew 装。brew 是 macOS 上最常用的软件包管理器——可以理解成命令行版的"应用商店"，专门装这类命令行工具：

# 安装 Git（大概几分钟，有进度条别关窗口）
brew install git

# 装完再验证一次
git --version
# 期望看到：git version 2.4x 或更高（本文校对时官方最新稳定版是 2.55.0）

附：这台 Mac 还没有 brew 怎么办

先检查有没有：

brew --version
# 有版本号输出就说明已安装，直接回第 1 步继续
# 若提示 command not found，去 brew.sh 官网复制那行安装命令
# （官网只有一行安装命令，从官网复制最安全，不要从博客复制）

brew 的安装过程可能需要几分钟，并要求你按回车确认，看到 Installation successful! 即可。装完关掉终端重开一个，再执行 brew install git。还有一个应急选项：执行 xcode-select --install 会装上苹果官方的命令行工具（含一份 Git），但版本偏旧，适合应急。

第 2 步：告诉 Git 你是谁（只需做一次）

每一次提交都会盖上"作者"戳，所以要先写上名字和邮箱（邮箱建议用你注册 GitHub 的那个）：

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

# 检查是否写成功
git config --global --list
# 期望看到 user.name 和 user.email 两行

这里的 --global 表示"对这台电脑上的所有仓库生效"，所以只需要做一次。

第 3 步：让 Git 和 GitHub 相认——三种方式选一种

从 2021 年 8 月 13 日起，GitHub 不再接受用登录密码做 Git 操作的认证了（这是官方公告里写明的）。也就是说，你必须用下面三种中的一种，别再用密码试了。新手推荐方式 A。

方式 A（推荐新手）：装 gh，一路按提示走

# 方式 A（推荐新手）：装 GitHub 官方命令行 gh，一路按提示登录
brew install gh
gh auth login
# 按提示选 GitHub.com → HTTPS → Yes（记住凭证）→ 用浏览器授权码登录

# 登录成功后验证
gh auth status
# 期望看到：Logged in to github.com as 你的用户名

顺便说一句：gh auth login 会帮你把 Git 的凭证也配好，之后你甚至可以用 gh 直接在命令行建仓库、开 PR，不必开浏览器。

方式 B：不用 gh，用令牌 + macOS 钥匙串

令牌（Personal Access Token，官方缩写 PAT）是一串长得像密码的字符，用来代替登录密码。先告诉 macOS 帮你记住它：

# 方式 B：不用 gh，用系统钥匙串记住令牌
git config --global credential.helper osxkeychain
# 之后第一次 push 时输入 GitHub 用户名 + 令牌（不是登录密码），
# macOS 会把它存进"钥匙串"，以后不再反复要密码。

令牌到底点哪里生成？（GitHub 官方现在推荐另一种）

这是旧教程最容易过期的地方，注意看：GitHub 官方文档现在明确说推荐用"细粒度令牌"（fine-grained token），而不是老的 classic 令牌。两者入口都在同一个地方，但能选的权限粒度不同。按下面点：

方式 C：SSH 密钥（以后可能会想换）

如果你打算长期频繁推送，可以在本机生成一对密钥：一把私钥留在自己电脑上（绝不外传），一把公钥贴到 GitHub 上。官方文档现在默认推荐用 ed25519 这种密钥算法（你不需要懂它的数学原理，照抄即可）：

# 1. 生成一对密钥（一路回车即可，密码短语可留空）
ssh-keygen -t ed25519 -C "你的邮箱@example.com"

# 2. 把公钥复制到剪贴板（macOS 自带 pbcopy）
pbcopy < ~/.ssh/id_ed25519.pub

# 3. 去 GitHub 网页：头像 → Settings → SSH and GPG keys → New SSH key，粘贴保存
# 4. 验证（看到 successfully authenticated 即成功）
ssh -T git@github.com

# 5. 如果仓库原本绑的是 HTTPS 地址，一条命令换成 SSH
git remote set-url origin git@github.com:你的用户名/仓库名.git

第 4 步：一次配好三个全局开关

这三个开关能省掉后面很多莫名其妙的麻烦，建议照抄：

# macOS 用户：提交时自动把换行符转成 LF，避免和 Windows 协作者互相"整行标红"
git config --global core.autocrlf input

# 新仓库默认分支叫 main（和 GitHub 新建仓库保持一致）
git config --global init.defaultBranch main

# 让中文文件名在 git status 里正常显示，而不是 \350 这种转义
git config --global core.quotepath false

验证：4 条命令确认环境 OK

git --version
# → git version 2.x
git config --global --list
# → 能看到 user.name / user.email / credential.helper 等
gh auth status
# → Logged in（如果你装了 gh；没装则跳过这条）
echo "env-ok"
# → 终端本身工作正常（排错用，确认你没贴错窗口）

04最小例子：10 分钟把第一个仓库推上 GitHub

这一节是一条完整闭环：本地建仓库 → 写文件 → 提交 → 推到 GitHub → 在网页上看到它。全程照抄，路径里的中文换成你自己的名字即可。

步骤 1：本地初始化

# ---- 步骤 1：本地初始化 ----
mkdir ~/Desktop/hello-git
cd ~/Desktop/hello-git
git init
# 期望：Initialized empty Git repository ...
ls -a
# 期望：能看到 .git 目录（Git 的"大脑"）

步骤 2：写文件 + 第一次提交

# ---- 步骤 2：写文件 + 第一次提交 ----
echo "Hello, Git!" > hello.txt
git status
# 期望：hello.txt 显示为 Untracked（Git 还不认识它）
git add hello.txt
git status
# 期望：hello.txt 变成 new file（已进暂存区）
git commit -m "第一次提交：你好 Git"
# 期望：[main ...] 1 file changed ...
git log --oneline
# 期望：看到你刚写的提交备注（历史链上有第一张照片了）

步骤 4：绑定 GitHub 并推送

# ---- 步骤 4：绑定 GitHub 并推送 ----
# 把下面地址里的"你的用户名"换成你自己的（仓库页绿色按钮 Code 里能复制）
git remote add origin https://github.com/你的用户名/hello-git.git
git branch -M main
git push -u origin main
# 期望：出现 Writing objects / 100%，最后有 "branch 'main' set up to track"
# 验证：刷新 GitHub 仓库网页，看到 hello.txt 和提交备注即成功！

变体：如果建仓库时勾了 README 怎么办

上面要求建"空仓库"是有原因的：空仓库没有任何提交，直接推不会冲突。如果你已经勾了 README（远端比本地多一次提交），二选一：

# 方案 A（推荐新手）：删掉重建一个空仓库，最干净
# GitHub 仓库页 → Settings → 最下方 Delete this repository
# 重建时不要勾 Add a README，然后按本章步骤 4 推送

# 方案 B：把远端的 README 先拉下来合并，再推（多学一招 pull）
git remote add origin https://github.com/你的用户名/hello-git.git
git branch -M main
git pull origin main --allow-unrelated-histories
# 会弹出编辑器让你写合并备注：直接 :wq 保存退出即可
git push -u origin main
# 验证：网页上同时看到 hello.txt 和 README.md

捷径：装了 gh 的话，一行命令建仓 + 推送

# 在项目目录里执行：自动在 GitHub 建仓库 + 绑定 + 推送当前分支
gh repo create hello-git --public --source=. --push
# --public 建公开仓（练习用）；想私有就换 --private
# --source=. 表示用当前目录；--push 表示建完直接推 main
# 验证：命令会打印出仓库网址，浏览器打开能看到文件即成功

05每天到底该敲哪几条命令？

日常 90% 的时间，你只会用到 8 个命令。记住这个循环：改（编辑）→ 看（status/diff）→ 存（add/commit）→ 同（pull/push）→ 查（log）。

每天开工三件套：status / pull / branch

# 看当前状态：我在哪个分支？哪些文件改了？处在哪个区？
git status

# 开工先同步远端，避免在旧代码上白干（等价于 fetch + merge，见术语表）
git pull

# 看本地有哪些分支，星号是当前所在
git branch
# 看远端有哪些更新可用（不合并，只看看）
git fetch origin

读懂 git status：它其实只说四件事

# 典型输出逐行翻译
git status
# On branch main              → 你在 main 分支上
# Your branch is up to date   → 本地和 GitHub 一样新，不用 pull
# Untracked files:            → 下面是新建的、Git 不认识的文件
#   new-feature.html          → 执行 git add new-feature.html 收编它
# modified: style.css         → 老文件被改了，add 后才能提交

改完代码的标准收尾：diff → add → commit → push

# 改了哪些行？提交前必看一眼，防止把调试垃圾带进去
git diff
# 只想看大概（哪些文件改了、加减几行）
git diff --stat

# 把改动挑进暂存区（可以只挑部分文件）
git add index.html style.css
# 全部挑进去（含新建/修改；删除文件要用 -A 才会收录删除动作）
git add -A

# 拍照存档：备注写清楚"做了什么"，别写"更新""修改"这种空话
git commit -m "首页 hero 加副标题与难度徽标"

# 同步到 GitHub（第一次推某分支要加 -u，后面直接 push 即可）
git push

"提交备注"到底该写什么？

三个月后回来翻历史时，备注是你唯一的线索。判断标准很简单：它能不能让未来的你说出"这次改了什么"。

查历史：log 是你的"监控录像"

# 紧凑版历史（一行一条，最常用）
git log --oneline -10

# 谁改了某文件、每次改了什么
git log --oneline -- hello.txt

# 图形化看分支分叉合并（--graph + --all + 装饰）
git log --graph --oneline --all -15

# 看某次提交到底改了哪些行
git show 提交号前7位

场景 1：给个人作品加云备份

目标：电脑里有个写了一半的网页，推到 GitHub 备份，换电脑也能继续。

cd ~/Desktop/我的作品
git init
git add -A
git commit -m "备份：作品当前进度"
# GitHub 网页建空仓库 my-work（不要勾 README），再执行：
git remote add origin https://github.com/你的用户名/my-work.git
git branch -M main
git push -u origin main
# 验证 1：刷新仓库网页，文件都在；换电脑执行 git clone 同一地址即可继续
git remote -v
# 验证 2：看到 fetch / push 两行都是你的仓库地址，说明绑定正确
git status
# 验证 3：显示 up to date，本地和云端一致，可以安心关机

clone：把别人的仓库整份搬回家

# 把 GitHub 上的仓库（含完整历史）下载到本地
git clone https://github.com/用户名/仓库名.git
cd 仓库名
git log --oneline -5
# 能看到完整历史，说明这是"全量搬家"而不只是下载最新文件

哪些文件不该进仓库？用 .gitignore 说清楚

密码、令牌、系统垃圾（.DS_Store，macOS 自动生成的目录信息文件）、依赖目录（node_modules，装依赖时下载的库文件）都不该进仓库。在仓库根目录建一个 .gitignore 文件，每行写一条"别管它"的规则：

# .gitignore 示例：# 开头是注释，每行一条规则
cat > .gitignore << 'EOF'
.DS_Store
node_modules/
dist/
.env
*.log
EOF
git add .gitignore
git commit -m "添加 .gitignore 忽略系统文件与密钥"

git rm --cached .env
git commit -m "从跟踪中移除 .env（文件保留在本地）"

06分支和合并：怎么开一条"平行宇宙"再合回来？

分支就是一条从主线岔出去的平行开发线。你在分支里随便改、随便提交，主线毫发无损；满意了再把它合回主线。它便宜到几乎零成本，所以"想试个方案"的正确反应是开分支，而不是复制整个文件夹。

开分支 → 改 → 合回：完整走一遍

# 新建并切换到功能分支（起名用英文小写+连字符）
git switch -c feature/hero-subtitle

# 在分支上改代码、提交（和主线互不干扰）
git add -A
git commit -m "hero 区补充副标题"

# 切回主线看看：刚才的改动不在这里，互不影响
git switch main

# 把分支的成果合回主线（先切到 main 再 merge）
git merge feature/hero-subtitle

# 合完确认无误，删掉已完成的分叉
git branch -d feature/hero-subtitle

分支相关命令速查

旧教程里的 checkout，现在该用 switch + restore

merge 和 rebase，我该用哪个？

# 安全流程：先更新主线，再把自己的分支变基到最新，解决冲突，最后合并
git switch main
git pull
git switch feature/hero-subtitle
git rebase main
# 若有冲突：按提示改完 → git add → git rebase --continue
# 想放弃变基：git rebase --abort（回到变基前状态）

场景 3：同时试两个方案，互不干扰

目标：首页想试"深色版"和"浅色版"两套 hero，哪个顺眼留哪个。

git switch -c try/dark-hero
# 改成深色版，提交存档
git add -A
git commit -m "尝试：深色 hero"
git switch main
git switch -c try/light-hero
# 改成浅色版，提交存档
git add -A
git commit -m "尝试：浅色 hero"
# 对比后决定要深色版：
git switch main
git merge try/dark-hero
git branch -d try/dark-hero try/light-hero
# 验证：git log --graph --oneline --all 能看到完整尝试轨迹

07GitHub 网页上那几个按钮在哪、点了会发生什么？

一个人用叫"备份"，多人用才叫"协作"。GitHub 官方推荐的轻量协作流程叫 GitHub Flow：一条分支做一件事，评审通过再合入主线。先认清网页上你真正会点的几个位置。

建仓库：New repository 页面上你只需要动三处

从开分支到 PR 被合入：GitHub Flow 六步

那几个容易吓到新手的标签页

评审人视角：怎么审别人的 PR（第一次当评审人看这里）

被邀请评审时不用慌，按这个顺序看，最多 10 分钟：

# 评审时把对方分支拉到本地验证（三步）
git fetch origin 对方分支名
git switch -c review/对方分支名 origin/对方分支名
# 本地运行验证，没问题回网页点 Approve，有问题在对应行留言
# 验完切回自己的活：git switch main + git branch -d review/对方分支名

给别人的仓库做贡献：fork + PR

没有别人仓库的写权限时，先 Fork（复刻一份到自己名下），改完从你的复刻版向原仓库发 PR。原作者的仓库通常记作 upstream（上游），你的复刻记作 origin：

# 1. 网页点 Fork，把仓库复制到自己名下
# 2. clone 自己名下那份到本地
git clone https://github.com/你的用户名/原仓库.git
cd 原仓库
# 3. 把原作者地址记为 upstream，方便以后同步更新
git remote add upstream https://github.com/原作者/原仓库.git
git remote -v
# 期望看到 origin（你的复刻）+ upstream（原作者）两组地址
# 4. 开分支改完推到 origin，再去网页向 upstream 发 PR

# 原作者更新后，把你的复刻同步到最新（定期做一次）
git switch main
git fetch upstream
git merge upstream/main
git push origin main

PR 说明模板（复制就用）

好的 PR 说明让评审人 1 分钟看懂。每次开 PR 时按这个填：

# PR 标题：动词 + 对象（一句话）
修复首页 hero 在小屏幕下换行错乱

# 正文按四段写：
改了什么：hero 副标题加 max-width，小屏字体降到 26px
为什么改：iPhone SE 下副标题溢出，横向出现滚动条
怎么验证：本地 375px 宽度截图 + git diff 确认只动了两处
风险：纯样式，无逻辑改动，可直接合入

08和别人改了同一个文件，冲突了怎么办？

冲突（merge conflict）指的是：同一文件的同一处被两个人改成了不同样子，Git 无法替你决定听谁的，于是停下合并、让你来选。它不是错误，是 Git 在守规矩——它宁可停下来问，也不擅自丢掉某个人的改动。

冲突处理三步

# 第 1 步：看哪些文件冲突了
git status
# 冲突文件会标为 both modified
# 第 2 步：打开文件，找冲突标记，手动留想要的部分，把标记行删干净，保存
# 第 3 步：告诉 Git 冲突解完了，继续合并
git add 冲突的文件
git commit
# 验证：git status 干净，git log 能看到合并提交

冲突标记长什么样？

打开冲突文件，你会看到三段线把两种版本夹在中间：

<<<<<<< HEAD
<p>欢迎来到我的主页</p>
=======
<p>欢迎来到我的个人主页</p>
>>>>>>> feature/hero-subtitle

解冲突的原则：看不懂就别删

怎么少遇到冲突

09出错了怎么救？先记住"改写历史"和"加一笔"

基本功够用后，这几招解决"改错了、合乱了、现场脏了"的实战问题。先记住结论：没推到 GitHub 的历史随便改；推上去的历史只用"加一笔"的方式修。

第 1 招：stash——手头有没做完的活，老板喊你先修线上 bug

# 把没做完的改动暂时"塞进抽屉"，工作区恢复干净
git stash push -m "做到一半的首页改版"
git status
# → 工作区干净了，可以放心切分支去修 bug

# bug 修完回来，把抽屉里的活取出来继续
git stash pop

# 抽屉里东西多时先列清单再取
git stash list

第 2 招：reset 和 revert——"撤销"分两种，别用反

git reset --hard HEAD~1
# 把最新一次提交直接抹掉
# 只许用在"还没 push"的本地提交！
# push 过的提交这么干，协作者会原地爆炸

git revert HEAD
# 新建一次"撤销上次"的提交
# 历史完整保留，谁都能看懂来龙去脉
# push 过的提交一律用它

# 三种 reset 力度（按需选用，默认 --mixed）
git reset --soft HEAD~1
# 回到"已暂存、未提交"状态（改动还在暂存区里）
git reset HEAD~1
# 回到"未暂存"状态（改动还在工作区，最常用）
git reset --hard HEAD~1
# 改动彻底丢弃！执行前务必 git status + git diff 确认

第 3 招：cherry-pick——只要别人分支里的一两个提交

# 把某次提交"摘"到当前分支（比如只拿一个修 bug 的提交）
git cherry-pick 提交号
# 摘错了？撤销这次摘取（原理同 revert，加一笔修复）
git cherry-pick --abort

第 4 招：tag——给重要版本贴"标签"

# 给当前版本打个 v1.0 标签（发版、上线、交作业都好用）
git tag v1.0
git push origin v1.0
# 标签默认不会跟着 push 走，必须单独推一次
git tag
# 列出所有标签

第 5 招：reflog——Git 的终极后悔药

reset --hard 用错了、分支误删了，别慌：reflog 记录了"当前指针"每一次移动，即使提交看起来丢了也能找回来。

# 场景：误删了分支 feature/hero-subtitle，想找回来
git reflog
# 输出类似：abc1234 HEAD@{3}: commit: hero 区补充副标题
# 找到误删分支最后一次提交的编号，基于它重建分支
git switch -c feature/hero-subtitle abc1234
# 验证：git log --oneline -3，熟悉的提交回来了

# 场景：reset --hard 回退过头了，想回到回退前的位置
git reflog
# 找到回退前 HEAD 所在的提交号，比如 def5678
git reset --hard def5678
# 验证：git log 确认历史恢复；文件内容也回来了

第 6 招：alias——给长命令起外号

# 以后 git st 就等于 git status，git lg 等于漂亮的历史图
git config --global alias.st status
git config --global alias.co switch
git config --global alias.lg "log --graph --oneline --all -15"
git st
git lg

第 7 招：场景 2——改崩了，一键回到 1 小时前

目标：调样式把页面调碎了，想回到上一次提交时的样子。分两种情况：

# 情况 A：改完还没 commit（工作区是脏的），只想丢弃某个文件的改动
git status
# 确认要丢弃的是 style.css
git restore style.css
git status
# 验证：style.css 回到上次提交时的内容，其他文件不受影响

# 情况 B：已经 commit 了几次，想整体回到上一个提交（且还没 push）
git log --oneline -5
# 找到想回去的那个提交号，比如 abc1234
git reset --hard abc1234
# 验证：git log 确认当前指针已指向目标；页面恢复正常
# 如果已经 push 过：改用 git revert HEAD（加一笔撤销，见本章）

一张表：我到底该用哪个？

10让 AI 大改代码前，Git 该怎么配合？

这是 AI 编程时代最重要的一条 Git 习惯：把 Git 当"存档点"，让 AI 改之前先存一次，改完用差异逐行审，坏了整单撤销。它便宜、可靠，而且是你对 AI 保持掌控感的最直接手段。

标准流程：存档 → 交给 AI → 审差异 → 决定去留

# AI 动手前：工作区必须是干净的（先把手头活提交了）
git status
# 必须看到 nothing to commit, working tree clean 才继续
git commit -m "存档：AI 重构前基线" --allow-empty
# 即使没改动也打个空提交当书签（可选但好用）
# ---- 把项目交给 AI 改 ----
# AI 改完后：先看它动了哪里，再决定要不要
git diff --stat
git diff
# 满意 → git add -A + git commit -m "AI 重构：xxx"
# 不满意 → git restore . 全部丢弃（还没 add 时）
# 已经 add 但没 commit → git reset 回到未暂存再 restore
# 已经 commit 了 → git reset --hard 回到基线提交号（本地未 push 才可用）

11新手最容易踩的坑有哪些？

新手 90% 的崩溃集中在下面这几个坑，每个都按"症状 → 原因 → 解药"给全。

7 个高频坑：症状 → 解药

detached HEAD（头指针分离）是什么，慌了怎么办

唯独这两件事，绝对不要做

# ❌ 不要这样做
git push --force
# push 被拒就硬推，覆盖队友代码
rm -rf .git
# 删除 .git 目录"重来"（历史全丢）
# 冲突文件直接全选"用我的"，不看对方改了啥

# ✅ 先看状态，再决定怎么走
git status
git log --oneline -5
# 重要现场先存档（stash 或另起分支备份）
git stash push -m "事故现场备份"
# 再 pull / 解冲突 / revert，加一笔修复

12命令速查表（一页纸）

左边是处境，右边是命令。先收藏，用时回来翻。

安装与身份

每日循环

分支与协作

救命命令

commit 备注前缀（英文团队常用）

常见报错 → 一条命令

13术语对照表

第三列不只翻译，更告诉你什么时候用它、别把它当成什么。

14常见问题

15报错对照表与排错四步

报错信息是英文别怕：复制红色那行，对照下表。90% 的新手报错就是这 8 条。

8 条最高频报错：症状 → 原因 → 解药

排错通用四步（背下来）

求助模板（直接复制去问 AI 或发群）

# 把下面三段输出贴出去，对方 1 分钟就能定位（记得打码令牌）
git status
git log --oneline -5
# + 你刚执行的命令 + 完整报错文字 + 你的目标（想达到什么效果）

99一句话总结

学完自测：6 题全对算出师

1. 不用看书写出"改完代码到推上 GitHub"的 4 条命令（答案：add → commit → pull → push，diff 是检查动作，见 05）。
2. 说出 commit 和 push 的区别（一句：前者存本地，后者同步云端）。
3. 说出 reset --hard 和 revert 分别用在什么时候（未推送的本地 vs 已推送的公共历史）。
4. 独立走完一次"分支 → 推送 → PR → 合并 → 删分支"（07 的六步流程）。
5. 故意制造一次冲突并亲手解掉（08 的三步）。
6. 给自己的仓库写一份 50 字以上的 README（含安装与运行步骤），并推上去。

下一步练习路线（3 天）

三天走完，你就具备了"独立用 Git + 在 GitHub 上协作"的完整能力。之后遇到新命令，先查 12 速查表，再看官方文档，足够应付日常绝大多数场景。

98参考来源与证据边界

本篇的关键事实都对照官方来源核对过（均为官方文档或官方博客，排名按"讲明白"与"可核实"兼顾的顺序）。

官方一手来源

• Git 官方网站（git-scm.com）—— Git 的定义原话（free and open source distributed version control system…）、下载入口与 Pro Git 全书。
• Git 官方参考文档（git-scm.com/docs）—— 其中 git-init 明确写了：初始分支名默认仍是 master，官方计划在 Git 3.0 改为 main，并可用 init.defaultBranch 配置；git-switch、git-restore 是拆分后的推荐写法。
• git/git 官方仓库（github.com/git/git/releases）—— 版本锚点：本文校对时最新稳定版是 v2.55.0，官方仓库的标签时间戳为 2026-06-29。
• GitHub Docs 入门（docs.github.com/en/get-started）—— "GitHub 的核心是 Git"的定义、GitHub Flow 的六步分支工作流、Set up Git 三步。
• GitHub Docs：管理个人访问令牌（managing-your-personal-access-tokens）—— 官方当前明确建议优先用细粒度令牌（fine-grained），而不是 classic 令牌；并说明命令行下推荐改用 GitHub CLI 或 Git Credential Manager。
• GitHub Blog：Git 操作的令牌认证要求（token-authentication-requirements-for-git-operations）—— 原文：Beginning August 13, 2021, we will no longer accept account passwords when authenticating Git operations on GitHub.com.
• GitHub Docs：关于大文件（about-large-files-on-github）—— 单文件超过 50 MiB 警告、超过 100 MiB 被拒；仓库建议小于 1 GB、强烈建议小于 5 GB。（另：100 MiB 是普通仓库上限，2 GiB 是 Git LFS 的单文件上限，两者不是一回事。）
• GitHub Docs：生成 SSH 密钥（generating-a-new-ssh-key）—— 默认推荐 ssh-keygen -t ed25519，旧系统才用 RSA 4096。
• GitHub CLI 文档（gh repo create 手册、GitHub CLI quickstart）—— gh auth login、gh repo create 与 --source / --push 的用法。
• GitHub Octoverse 2024（octoverse-2024）—— 规模数字：2023 年初开发者总数突破 1 亿，2024 年公开/私有项目总量约 5.18 亿。

本文自己做的核对

• 默认分支名：没有照抄"新仓库默认就叫 main"，而是去读了 Git 官方 git-init 文档原文，确认默认仍是 master、Git 3.0 才改 main、可用 init.defaultBranch 覆盖——所以文中的做法是显式配置，不是依赖默认值。
• 版本日期：2.55.0 的发布时间不是凭记忆写的，而是取官方仓库的标签时间戳（2026-06-29）核对。
• 令牌类型：核对 GitHub 官方文档时发现它已改为优先推荐细粒度令牌，而常见的旧教程只讲 classic，本文据此补上了这个区别。
• 大文件上限：核对官方文档的数据变量，确认 50 MiB / 100 MiB / 1 GB / 5 GB 四个数字；并纠正了"单次 push 2 GiB 上限"这一常见误传（2 GiB 是 Git LFS 的单文件上限）。

证据边界与时效

• 版本口径。本文校对于 Git @ 2.55.0（2026-06-29 发布），这是本文 learn:based-on 的锚点。Git 的核心命令多年稳定，但默认分支名、GitHub 网页按钮文案与令牌界面可能微调——这也是本文标 shelf-life=evolving 的原因。
• 没有做的事。本篇没有覆盖 CI/CD 流水线、团队权限与分支保护规则、Git 内部实现（对象存储格式、打包算法）；也没有提供 Windows 与 Linux 的安装步骤。
• 一处口径提醒。文中"90% 的新手报错""日常 90% 的时间"是经验性说法，不是统计结论；真正需要精确数字的地方（版本、文件上限、发布日期）都已标明出处。
• 网页描述可能过期。GitHub 的界面位置（如令牌入口、黄色提示条）本文按官方文档描述，若与你看到的页面不一致，请以 docs.github.com 当前页面为准。