Git 与 GitHub 完全入门指南：从零开始到日常协作

Thu, 17 Sep 2026 09:30:00 +0800

一、前言：为什么每个开发者都要学 Git 与 GitHub

如果你写过代码、保存过文档，就会知道一个常见的痛点：

报告_v1.docx
报告_v1_最终.docx
报告_v1_最终_真的不改了.docx
报告_v1_最终_真的不改了_老板说要改.docx

Git 的出现彻底解决了这个问题。它是一套分布式版本控制系统，可以精确记录文件的每一次改动，让你随时回退、对比、分支实验，并与他人无缝协作。

而 GitHub 是目前全球最大的代码托管平台，基于 Git 构建，提供了远程仓库、Pull Request、Issue、Actions、Pages 等一整套协作工具。

简单地说：

Git = 本地版本管理工具（命令行）
GitHub = 远端协作平台（网站 + 服务）

两者配合的典型场景就是：本地写代码 → Git 记录改动 → 推送到 GitHub → 团队成员从 GitHub 同步 → 通过 PR 合并代码。你正在看的这篇文章，就是 Hugo + Git + GitHub + Vercel 这条流水线自动构建发布的。

本文将从零开始，按"概念 → 安装 → 命令 → 协作 → 实战"的顺序，逐步带你掌握 Git 与 GitHub 的完整日常用法。

二、必须先理解的 8 个核心概念

在敲命令之前，请把下面这 8 个概念记牢。它们会贯穿你使用 Git 的每分每秒。

1. 仓库（Repository，简称 Repo）

存放你项目文件 + 所有改动历史的目录。一个项目对应一个仓库。

本地仓库：你电脑上的 .git 目录及其管理的文件
远程仓库：托管在 GitHub / GitLab / Gitee 等平台上的副本

2. 工作区、暂存区、版本库（三区模型）

这是 Git 最核心的状态机：

flowchart LR
 W["工作区
Working
你编辑的文件"]
 S["暂存区
Staged
下次提交的快照"]
 R["版本库
Repository
HEAD 指向的历史"]
 M["远程仓库
Remote
GitHub"]

 W -->|"git add"| S
 S -->|"git commit"| R
 R -->|"git push"| M
 M -.->|"git pull"| W
 S -.->|"git restore --staged"| W
 R -.->|"git reset"| W

 style W fill:#f59e0b,stroke:#b45309,stroke-width:2px,color:#fff
 style S fill:#3b82f6,stroke:#1e40af,stroke-width:2px,color:#fff
 style R fill:#10b981,stroke:#047857,stroke-width:2px,color:#fff
 style M fill:#8b5cf6,stroke:#6d28d9,stroke-width:2px,color:#fff

四个区域的作用：

工作区：你正在编辑的文件
暂存区：已标记"下次要提交"的快照（一个中间层，让你可以精确控制哪些改动进一次提交）
版本库：已经提交、永久保存的历史
远程仓库：托管在 GitHub / GitLab / Gitee 等平台上的副本，本质是版本库的远端镜像

不理解暂存区是初学者最大的卡点。记住一句话：暂存区是"草稿箱"，版本库是"档案柜"。你可以把多个改动分批放进草稿箱，分多次提交进档案柜。

3. 提交（Commit）

一次提交 = 一个带说明的快照。每次 commit 都有一个全球唯一的哈希值（如 a1b2c3d...），是回退、对比、定位的钥匙。

4. 分支（Branch）

指向某个 commit 的轻量指针。主分支默认叫 main（老项目可能是 master）。分支存在的意义是让你在不影响主线的情况下做实验。

5. HEAD

一个特殊的"指针"，永远指向你当前所在的位置（通常是某分支的最新 commit）。

6. 远程（Remote）

本地仓库对远端仓库的"昵称"，默认叫 origin，可以配多个（如 origin + upstream）。

7. 合并（Merge）vs 变基（Rebase）

把两条分支"合到一起"的两种不同方式：

merge：保留分支历史，会产生合并 commit
rebase：把当前分支"接到"目标分支顶端，历史是线性的（更干净，但会改写 commit 哈希）

8. 冲突（Conflict）

两个分支对同一文件的同一行做了不同的修改，Git 会停下来让你手动决定保留哪一方。

三、环境准备：安装 Git 与注册 GitHub

1. 安装 Git

Windows

方式 A（推荐）：Git 官网下载安装包，一路 Next
方式 B（包管理器）：winget install Git.Git
安装完打开 Git Bash（Git 自带的终端），后续命令都在这里敲

macOS

自带 Xcode Command Line Tools：xcode-select --install
或 Homebrew：brew install git

Linux（Debian/Ubuntu）

sudo apt update && sudo apt install git -y

验证安装

git --version
# 输出示例：git version 2.45.0

2. 首次配置：告诉 Git 你是谁

必须配，不然无法 commit：

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

邮箱建议用 GitHub 注册邮箱，这样你的 commit 在 GitHub 上会显示头像。

常用配置项：

# 默认分支名（GitHub 新仓库默认是 main，老项目可能是 master）
git config --global init.defaultBranch main

# 中文文件名不转义（Windows 常用）
git config --global core.quotepath false

# 提交时自动转换 CRLF（推荐 Windows 用户）
git config --global core.autocrlf true
# macOS / Linux 用户
git config --global core.autocrlf input

# 漂亮的 log（强烈推荐，后面会介绍怎么配别名）
git config --global alias.lg "log --oneline --graph --decorate --all"

查看所有配置：

git config --list

3. 注册 GitHub 账号

打开 github.com → Sign up
选用户名（这会是你的个人主页域名的一部分，如 github.com/xxx，慎重）
邮箱 + 密码 + 验证
建议勾选"接收产品更新邮件"（了解新功能）

4. 配置 SSH 密钥（强烈推荐，省去每次输入密码）

第一步：生成密钥

ssh-keygen -t ed25519 -C "你的邮箱@example.com"
# 一路回车，使用默认路径与空密码即可

生成的密钥文件在：

文件	用途	路径（Windows / macOS·Linux）
`id_ed25519`	私钥，留在本地，绝不能泄露	`C:\Users\你的用户名\.ssh\id_ed25519` / `~/.ssh/id_ed25519`
`id_ed25519.pub`	公钥，需要上传到 GitHub	同目录下的 `.pub` 文件

第二步：把公钥告诉 GitHub

# 查看并复制公钥内容
cat ~/.ssh/id_ed25519.pub

打开 GitHub → 右上角头像 → Settings → SSH and GPG keys → New SSH key → Title 任意，Key 类型选 Authentication，把公钥粘贴进去 → Add SSH key。

第三步：测试连通性

ssh -T git@github.com
# 首次会问是否信任，输入 yes
# 看到 "Hi <用户名>! You've successfully authenticated..." 就成功了

HTTPS vs SSH：HTTPS 每次 push 要输用户名密码（或 PAT），SSH 配置一次永久免密。强烈推荐 SSH。

四、最小工作流：3 条命令搞定本地版本管理

假设你已经在本地有一个项目目录 my-project，想用 Git 管理它。

第 1 步：初始化仓库

cd my-project
git init

执行后目录下会多出一个 .git 隐藏目录，这就是 Git 的"大脑"。

第 2 步：查看状态

git status

这是你最常用的命令之一，随时告诉你"现在哪些文件被改了、哪些被暂存了"。

第 3 步：第一次提交

# 把所有文件加入暂存区
git add .

# 提交到版本库
git commit -m "第一次提交：初始化项目"

到这里，本地 Git 仓库就建好了。完整流程如下：

flowchart LR
 A[1. 创建文件
echo > README.md] --> B[2. git init
初始化仓库]
 B --> C[3. git add
加入暂存区]
 C --> D[4. git commit
写入版本库]
 D --> E([git log
查看历史])

完整命令行版（可直接复制执行）：

echo "# My Project" > README.md
git init
git add README.md
git commit -m "Initial commit"
git log --oneline # 查看提交历史

五、必须吃透的 12 条核心命令

下面这些命令覆盖 90% 的日常使用，务必熟记。

命令	作用	常用场景
`git status`	查看工作区与暂存区状态	任何时候不确定"现在是什么状态"
`git add <file>`	把文件加入暂存区	修改后准备提交
`git commit -m "msg"`	提交暂存区的内容到版本库	每次"完成一个小功能"
`git log`	查看提交历史	想看过去做过什么
`git diff`	查看未暂存的改动	提交前确认改了什么
`git diff --staged`	查看已暂存的改动	提交前最后确认
`git restore <file>`	撤销工作区修改（未暂存）	改错了想回退
`git restore --staged <file>`	把文件从暂存区撤回到工作区	add 多了想撤销
`git reset --hard <commit>`	回退到某个 commit（危险）	想彻底回到过去
`git revert <commit>`	新建一个 commit 撤销指定 commit	已推送的内容要回退
`git stash`	临时藏起来未提交的改动	切分支前不想提交
`git stash pop`	把藏起来的改动恢复回来	切回分支后继续改

详细解释与示例

`git log`：看历史

git log # 完整输出
git log --oneline # 每个 commit 一行（推荐）
git log --oneline --graph --all # 图形化显示所有分支
git log --author="你的名字" # 按作者过滤
git log --since="2026-01-01" # 按时间过滤
git log -p <file> # 看某个文件的全部改动历史

`git diff`：看差异

git diff # 工作区 vs 暂存区（未 add 的改动）
git diff --staged # 暂存区 vs 版本库（已 add 未 commit 的改动）
git diff main feature # 两个分支的差异
git diff HEAD~1 HEAD # 当前 commit vs 上一个 commit

`git add`：精确控制粒度

git add file.txt # 单个文件
git add dir/ # 整个目录
git add . # 当前目录下所有改动
git add -p # 交互式：逐个 hunk（代码块）选择是否 add（高级但极好用）

`git commit`：写好提交说明

好习惯是一行不超过 50 字的祈使句，如：

✅ fix: 修复用户登录失败问题
✅ docs: 更新 README 安装步骤
❌ 改了点东西（太模糊）
❌ Updated some files.（同义反复）

更复杂的多行说明：

git commit -m "feat: 增加用户导出功能" -m "- 支持 CSV 格式" -m "- 修复分页边界问题"

或者用编辑器写：

git commit # 会打开默认编辑器，写完保存关闭即提交

撤销类（重点中的重点）

# 撤销工作区的修改（文件回到上次 add 或 commit 的状态）
git restore file.txt

# 把已 add 的文件撤回到工作区（暂存区取消，但工作区保留）
git restore --staged file.txt

# 修改最后一次 commit（追加改动 / 修改说明）
git commit --amend
# ⚠️ 注意：amend 会改写 commit hash，**只对**未推送的 commit 使用

# 回退到指定 commit（--hard 会丢掉之后所有改动，慎用）
git reset --hard HEAD~1 # 回退 1 个 commit
git reset --hard a1b2c3d # 回退到指定哈希

# 安全回退（已推送到远端时用这个，会产生新 commit 撤销改动）
git revert HEAD

黄金法则：reset 用来操作本地未推送的 commit；revert 用来操作已经推送到远端的 commit。

`git stash`：临时存放

切分支时手头还有改动没提交，又不想带过去污染分支：

git stash # 藏起来
git stash list # 查看藏起来的列表
git stash pop # 恢复并删除 stash
git stash apply stash@{0} # 恢复但不删除（可恢复多次）
git stash drop stash@{0} # 删除指定 stash
git stash clear # 清空所有 stash

六、把仓库推上 GitHub：远程协作入门

1. 在 GitHub 上创建空仓库

登录 GitHub → 右上角 + → New repository
Repository name：my-project（最好和本地目录同名）
选 Public（公开，任何人可看）或 Private（私有）
不要勾选 “Add a README” / “.gitignore” / “license”（避免和本地冲突）
点 Create repository

2. 本地关联远端

cd my-project # 进入你的本地仓库

# 添加远程仓库（SSH 方式，推荐）
git remote add origin git@github.com:你的用户名/my-project.git

# 如果你用的是 HTTPS
# git remote add origin https://github.com/你的用户名/my-project.git

# 查看远程仓库
git remote -v

3. 第一次推送

# 推送 main 分支到 origin
git push -u origin main

# -u 是 --set-upstream 的简写，建立本地分支与远端分支的关联
# 之后只需 git push 即可

4. 后续日常推送

git add .
git commit -m "feat: xxx"
git push # 不再需要写 origin main，因为 -u 已经记住

5. 从远端拉取

git pull # 拉取并自动合并（= git fetch + git merge）
git fetch # 只拉取不合并（更安全，适合先看看远端有什么）

建议：日常用 pull，遇到不确定的远端变更用 fetch 先看一眼。

七、分支管理：团队协作的核心武器

分支是 Git 区别于其他版本控制系统的灵魂。它让你在不影响主线的情况下自由实验。

1. 分支的直观理解

gitGraph
 commit id: "A"
 commit id: "B"
 branch feature-login
 checkout feature-login
 commit id: "C"
 commit id: "D"
 commit id: "E"
 checkout main
 commit id: "F"
 commit id: "G"
 merge feature-login

main 在 B 之后分叉出 feature-login，你在 feature-login 上做了 C/D/E，主线 main 继续往前走到 F/G。等你做完功能后，把 feature-login 合并回 main，历史就合到一起了。

2. 常用分支命令

# 查看所有本地分支
git branch

# 查看所有分支（包括远端）
git branch -a

# 创建分支
git branch feature-login

# 切换到指定分支（旧语法）
git checkout feature-login

# 创建并切换（新语法，推荐）
git switch -c feature-login
# 或：git checkout -b feature-login

# 删除已合并的分支
git branch -d feature-login

# 强制删除未合并的分支（会丢改动，慎用）
git branch -D feature-login

# 重命名当前分支
git branch -m new-name

3. 合并分支

Merge 方式（保留历史）

# 切回主分支
git switch main

# 把 feature 分支合并进来
git merge feature-login

合并后会产生一个合并 commit，完整保留分支历史。

Rebase 方式（线性历史）

# 在 feature 分支上
git switch feature-login
git rebase main
# feature 分支的 commit 会被"重放"到 main 顶端

之后切回 main 做 fast-forward merge，历史就是干净的直线。

何时用哪个：

个人本地分支、还没推送：随便 rebase，历史更干净

多人共享的远端分支：绝对不要 rebase，会扰乱其他人的本地历史

不确定时：用 merge

两种方式的结果对比（同一起点 B，分支 feature 上做了 C/D/E，主线在 B 之后又走了 F）：

%% merge 方式：保留分支拓扑，多一个合并 commit
gitGraph
 commit id: "A"
 commit id: "B"
 branch feature
 checkout feature
 commit id: "C"
 commit id: "D"
 commit id: "E"
 checkout main
 commit id: "F"
 merge feature tag: "merge commit"

%% rebase 方式：feature 被"重放"到 main 顶端，main merge 时是 fast-forward
gitGraph
 commit id: "A"
 commit id: "B"
 branch feature
 checkout feature
 commit id: "C'"
 commit id: "D'"
 commit id: "E'"
 checkout main
 commit id: "F"
 merge feature tag: "fast-forward"

4. 冲突解决

当你 merge / rebase / pull 时，两个分支对同一行做了不同修改，Git 会暂停并提示：

CONFLICT (content): Merge conflict in src/app.js
Automatic merge failed; fix conflicts and then commit the result.

打开冲突文件，会看到冲突标记：

<<<<<<< HEAD
console.log("main 分支的代码");
=======
console.log("feature 分支的代码");
>>>>>>> feature-login

手动编辑保留正确内容，删除 <<<< ==== >>>> 标记，然后：

git add src/app.js
git commit # 完成合并
# 如果是 rebase，继续：git rebase --continue

5. 一个推荐的工作流（Git Flow 简化版）

适合个人 / 小团队：

分支	用途	从哪拉	合并到
`main`	稳定版本	—	—
`dev`	开发集成	`main`	`main`
`feature/*`	新功能	`dev`	`dev`
`fix/*`	修 bug	`dev`	`dev`

日常节奏：在 feature/xxx 上写功能 → PR 合并到 dev → 稳定后 dev 合并到 main。

八、Pull Request：团队协作的灵魂

Pull Request（PR，GitLab 上叫 Merge Request）是 GitHub 的"代码评审"机制。

1. 典型流程

flowchart TD
 A[Fork 主仓库
到自己的账号] --> B[Clone 到本地
git clone fork-url]
 B --> C[添加 upstream 远程
指向原作者仓库]
 C --> D[新建功能分支
git switch -c fix-bug]
 D --> E[改代码 + add + commit
+ push 到 fork 分支]
 E --> F[在 GitHub 创建 PR
Compare & pull request]
 F --> G{评审结果}
 G -->|需修改| H[本地继续修改
+ 重新 push]
 H --> F
 G -->|通过| I[Merge 到主分支]
 I --> J([本地 PR 已合并])

要点展开：

Fork 主仓库（在 GitHub 网页上点 Fork）到自己的账号下
克隆 fork 仓库到本地：git clone git@github.com:你的用户名/project.git
添加上游：git remote add upstream git@github.com:原作者/project.git
创建分支：git switch -c fix-bug
改代码 → add → commit → push 到自己 fork 的 fix-bug 分支
在 GitHub 上点 Compare & pull request → 写标题和说明 → 创建 PR
项目维护者评审（review）→ 讨论 → 同意后合并（merge）

2. 写好 PR 说明

好的 PR 模板：

## 改了什么
- 新增 xxx 接口
- 修复 yyy bug

## 怎么测
1. 启动 xxx 服务
2. 调用 xxx 接口
3. 看到返回 zzz

## 截图 / 日志
（可选）

## 相关 Issue
Closes #123

3. Code Review 基本礼仪

对别人的 PR：就事论事、对代码不对人；提问而非命令（“这里我不太理解” vs “这里写错了”）
对自己的 PR：保持小颗粒度（一个 PR 只做一件事）；自己先 review 一遍再请求评审

九、撤销与恢复：挽救你的"误操作"

1. 撤销工作区的改动

git restore file.txt # 撤销单个文件
git restore . # 撤销所有改动

2. 撤销暂存

git restore --staged file.txt # 撤销单个文件的暂存
git restore --staged . # 撤销所有暂存

3. 撤销最后一次 commit（未推送）

git commit --amend # 改写最后一次 commit
# 或
git reset --soft HEAD~1 # 撤销 commit 但保留改动在暂存区
git reset HEAD~1 # 撤销 commit 改动回到工作区
git reset --hard HEAD~1 # 撤销 commit 并丢弃所有改动（⚠️ 危险）

4. 撤销已推送的 commit

# 生成一个新 commit 撤销指定 commit 的改动（推荐，保留历史）
git revert a1b2c3d
git push

# 或者直接回退远端分支（⚠️ 危险，会影响其他人）
git reset --hard HEAD~1
git push --force-with-lease

git push --force 是危险操作，会覆盖远端历史，可能让协作者的工作丢失。优先用 --force-with-lease（如果远端有你不知道的新 commit，会拒绝覆盖）。

5. 找回丢失的 commit

git reflog # 查看所有 HEAD 移动记录（30 天内）
# 找到你想要的哈希，然后
git reset --hard <哈希> # 回到那个 commit

reflog 是 Git 的"后悔药"，大多数丢失的 commit 都能从这里找回来。

6. 恢复误删的分支

git reflog | grep "分支删除前的提交"
git switch -c branch-name <哈希>

十、.gitignore：忽略不该追踪的文件

你不想把 node_modules/、__pycache__/、.env、*.log、dist/ 这些文件提交到仓库。.gitignore 就是干这个的。

1. 创建方式

方式 A：仓库根目录创建 .gitignore 文件
方式 B：hugo new site 等命令会自动生成模板
方式 C：GitHub 仓库创建时直接选模板

2. 常用模板（按语言 / 框架）

Node.js

node_modules/
dist/
.env
npm-debug.log*
yarn-debug.log*
yarn-error.log*

Python

__pycache__/
*.py[cod]
*.egg-info/
.venv/
venv/
.env

Hugo

public/
resources/_gen/
.hugo_build.lock

通用建议

.DS_Store # macOS
Thumbs.db # Windows
*.swp # Vim
.vscode/ # VSCode 个人配置（按需）
.idea/ # JetBrains 个人配置（按需）

3. 已经被追踪的文件怎么办？

.gitignore 只对未追踪的文件生效。如果某个文件已经被 git add 过了，需要先取消追踪：

# 从版本库移除但保留本地文件
git rm --cached file.txt

# 然后提交
git commit -m "chore: 从追踪列表移除 file.txt"

4. 一行速记

模式	含义
`*.log`	所有 .log 文件
`/TODO`	根目录的 TODO 文件
`build/`	所有 build 目录
`doc/*.txt`	doc 目录下（不递归）的 .txt
`doc/*/.txt`	doc 目录及其子目录的所有 .txt
`!README.md`	否定，不忽略这个

十一、GitHub 进阶功能

1. Issue：任务与缺陷追踪

任何人都可以在公开仓库提 Issue
标题 + 描述 + 标签（bug / enhancement / question / documentation）
用 #123 在 commit / PR 中引用，会自动建立双向链接
在 commit message 写 Fixes #123 或 Closes #123，合并 PR 后会自动关闭对应 Issue

2. Projects：看板

类似 Trello 的项目看板，可以把 Issue / PR 拖拽到不同列（Todo / In Progress / Done），适合个人任务管理。

3. Wiki：项目文档

仓库内的多页面文档系统，适合写详细文档、API 参考、FAQ。

4. GitHub Actions：自动化 CI/CD

在仓库的 .github/workflows/ 下放 YAML 文件，可以做到：

PR 触发自动跑测试
push 后自动部署（你正在看的 Hugo 博客就是这条链路）
自动发版、自动发 release notes

示例 .github/workflows/hugo.yml：

name: Deploy Hugo to GitHub Pages
on:
 push:
 branches: [main]
jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: peaceiris/actions-hugo@v3
 with:
 hugo-version: 'latest'
 extended: true
 - run: hugo --minify
 - uses: actions/upload-pages-artifact@v3
 with:
 path: ./public
 - id: deployment
 uses: actions/deploy-pages@v4

5. GitHub Pages：免费静态网站

仓库 Settings → Pages → 选分支 → 即可发布静态站点。个人博客 / 项目文档最简方案。

6. Gist：代码片段

适合分享单文件 / 小段代码。

十二、常见坑与最佳实践

1. 提交粒度

✅ 一个 commit 只做一件事：修一个 bug / 加一个功能 / 改一处文档
❌ 一次 commit 改 50 个文件、跨多个功能

好粒度让你能精准回退、精准 cherry-pick。

2. 不要提交的东西

类型	例子	处理
编译产物	`dist/` `build/` `public/`	加 `.gitignore`
依赖	`node_modules/` `vendor/`	加 `.gitignore`
敏感信息	`.env` `config.json` 里的密码	加 `.gitignore`
IDE 配置	`.idea/` `.vscode/`（团队统一除外）	加 `.gitignore`
系统文件	`.DS_Store` `Thumbs.db`	加 `.gitignore`
大型二进制	视频、设计稿 PSD	用 Git LFS

3. 已经提交了敏感信息？

立刻做两件事：

改密码 / 撤销凭证
从 Git 历史清除（用 git filter-repo 或 BFG Repo-Cleaner）

只在最新 commit 改不够，必须清理历史。如果推到 GitHub 是公开仓库，敏感信息相当于已经泄露。

4. 大文件：用 Git LFS

Git 不擅长管理大型二进制文件（几十 MB 以上）。Git LFS（Large File Storage）会用指针文件替代真实内容，存到独立存储。

git lfs install
git lfs track "*.psd"
git add .gitattributes
git add *.psd
git commit -m "add design files via LFS"

5. 避免 force push 到共享分支

git push --force-with-lease # 安全版：远端没新 commit 才允许

绝对禁止 git push --force 到 main / dev 等多人协作的分支。

6. 别在主分支上直接改

永远在 feature 分支上改，PR 合并。即便是个人项目，也养成这个习惯。

7. commit message 模板

在仓库根目录放 .gitmessage：

# <type>(<scope>): <subject>
#
# body (optional)
#
# footer (optional)

# type: feat fix docs style refactor test chore

配置：

git config commit.template .gitmessage

8. 提速：别名与工具

# 配别名（写到 ~/.gitconfig 也行）
git config --global alias.st status
git config --global alias.co switch
git config --global alias.br branch
git config --global alias.lg "log --oneline --graph --decorate --all"
git config --global alias.unstage "restore --staged"

之后 git st 就等于 git status。

9. 出错了怎么办？

任何误操作，先 git reflog。它会告诉你 HEAD 走过的每一步，绝大多数情况都能恢复。

十三、推荐学习路径

第一周：掌握第 1～6 节命令，足够日常提交、推送
第二周：学分支管理与冲突处理
第三周：上手一次 PR 流程（哪怕是自己的仓库）
第一个月：配置 SSH、.gitignore、GitHub Actions
持续练习：用 Git 管理一切文本内容（博客 / 笔记 / 配置文件）

十四、速查表（Cheat Sheet）

仓库操作

git init # 初始化仓库
git clone <url> # 克隆远端仓库
git remote add origin <url> # 添加远程
git remote -v # 查看远程

文件操作

git status # 查看状态
git add <file> # 加入暂存区
git add . # 暂存区所有改动
git commit -m "msg" # 提交
git commit --amend # 改写最后一次 commit
git restore <file> # 撤销工作区改动
git restore --staged <file> # 撤销暂存
git rm <file> # 删除文件并暂存
git mv <old> <new> # 重命名文件并暂存

查看历史

git log # 完整历史
git log --oneline # 简洁历史
git log --graph --all # 图形化所有分支
git diff # 工作区 vs 暂存区
git diff --staged # 暂存区 vs 版本库
git show <commit> # 看某次提交详情

分支

git branch # 列出本地分支
git branch -a # 列出所有分支
git branch <name> # 创建分支
git switch <name> # 切换分支
git switch -c <name> # 创建并切换
git branch -d <name> # 删除已合并分支
git branch -D <name> # 强制删除分支

合并

git merge <branch> # 合并分支
git rebase <branch> # 变基
git rebase -i HEAD~3 # 交互式 rebase（改写最近 3 个 commit）

远程

git fetch # 拉取远端（不合并）
git pull # 拉取并合并
git push # 推送到远端
git push -u origin <branch> # 首次推送并建立关联
git push --force-with-lease # 安全强推

撤销与恢复

git reset --soft HEAD~1 # 撤销 commit 改动留暂存区
git reset --mixed HEAD~1 # 撤销 commit 改动回工作区
git reset --hard HEAD~1 # 撤销 commit 并丢弃改动
git revert <commit> # 新 commit 撤销指定 commit
git stash # 临时存放改动
git stash pop # 恢复并删除 stash
git reflog # 查看 HEAD 历史（救命用）

十五、写在最后

Git 的学习曲线前陡后缓：前 2 小时会觉得概念很多、命令记不住；用满一周后会有"豁然开朗"的感觉；用满一个月后你就再也离不开它了。

不要试图一次背完所有命令。先记住 5 条：add / commit / push / pull / status，跑起来再说。其它的查速查表或本文就好。

最后送一句 Git 社区的老话：

“Commit early, commit often, push frequently.” （早提交，多提交，常推送。）

祝你在版本控制的路上少踩坑、多享受。

教程 on 我的博客