DRAFT 从零到精通：Git完整指南，告别“只会add/commit/push”的时代

约 9177 字大约 31 分钟

2026-04-19

你是否也曾经历过这样的场景：团队协作时，别人的分支操作让你眼花缭乱；不小心改坏了代码，却不知道怎么安全恢复；想要整理提交历史，却搞乱了整个仓库？本文将带你从Git小白成长为团队中的Git高手。

作为一名全栈开发者，我在过去8年的职业生涯中发现：Git技能是区分初级和高级开发者的重要标志。不是因为你用了多少花哨的命令，而是因为熟练的Git操作能让你在团队协作、代码维护、问题排查中游刃有余。

本文不是又一个枯燥的命令列表，而是一个按照真实学习路径设计的完整教程。我将用my-blog这个前端项目作为贯穿始终的案例，带你从零开始，一步步掌握Git的核心精髓。

为什么你需要这份指南？

市面上有很多Git教程，但它们往往存在这些问题：

❌ 命令堆砌：给你一堆命令却不解释使用场景
❌ 脱离实战：例子过于简单，无法应对真实项目复杂度
❌ 缺乏系统性：东一榔头西一棒子，学完还是不会用

本文将解决这些问题，通过：

✅ 渐进式学习：从配置到团队协作，符合真实学习曲线
✅ 实战导向：每个命令都有具体场景和示例
✅ 避坑指南：标注危险操作和最佳实践
✅ 完整闭环：提供从项目创建到版本发布的全流程案例

让我们开始这段Git学习之旅吧！

第一阶段：打造你的专属Git环境（一次配置，终身受益）

还记得我第一次用Git时的尴尬经历吗？提交代码后，GitHub上显示的作者是"unknown"——因为我忘记配置用户信息。更糟糕的是，每次写提交信息都要在vim编辑器里挣扎半天。

配置Git环境就像装修你的开发工作室：好的工具配置能让你事半功倍。这一阶段的所有配置都是全局的，设置一次，所有项目受益。

为什么配置很重要？

身份识别：团队协作中，清晰的作者信息让责任追溯变得简单
效率提升：合理的别名和编辑器设置能节省大量时间
习惯养成：统一的配置帮助形成一致的开发习惯

1.1 身份配置：告诉Git你是谁

这是Git配置的第一步，也是最容易忘记的一步。没有正确配置身份信息，你的提交就像匿名信一样，团队无法追溯。

# 设置全局用户名（推荐使用英文名或拼音）
git config --global user.name "zhangsan"

# 设置全局邮箱（必须与GitHub/GitLab账号邮箱一致）
git config --global user.email "zhangsan@qq.com"

# 验证配置是否生效
git config --list | grep user

为什么要与GitHub邮箱一致？ 当你的提交推送到远程仓库时，GitHub会通过邮箱匹配你的账户，自动将提交关联到你的个人主页，展示贡献图。

真实案例：我曾遇到一个团队，新成员提交代码后，代码审查时发现作者显示为"unknown"。排查后发现他使用了个人邮箱而非公司邮箱，导致GitHub无法识别。这个小问题让团队花了半小时才找到提交者。

1.2 环境优化：让Git更懂你

好的开发环境应该适应你的习惯，而不是让你去适应工具。这几个配置能显著提升你的Git使用体验。

# 1. 设置默认分支名（从master改为main，符合现代命名规范）
git config --global init.defaultBranch main

# 2. 设置默认编辑器（告别vim恐惧症）
git config --global core.editor "code --wait"

# 3. 开启颜色显示（一眼识别文件状态）
git config --global color.ui auto

配置详解

1. 默认分支名：为什么是main？

历史背景：Git早期使用master作为默认分支名
行业变迁：2020年GitHub将默认分支改为main，Git随后跟进
实践建议：新项目统一使用main，现有项目可逐步迁移

2. 编辑器配置：VS Code的妙用

code --wait：用VS Code打开提交信息编辑器，编写体验远好于vim
如果你用其他编辑器，只需替换为对应命令：
- Sublime Text: subl -w
- Atom: atom --wait
- VSCode Insiders: code-insiders --wait

3. 颜色显示：视觉化状态

绿色：新增文件
红色：删除/修改文件
蓝色：重命名文件
一目了然，减少认知负担

1.3 命令别名：开发者的效率神器

如果你还在输入完整的 git status、git checkout，那么你每天至少浪费了5分钟在打字上。命令别名就是为你准备的效率工具。

# 设置别名的基础语法
git config --global alias.短命令 "长命令"

# 我的个人推荐配置（8年经验总结）
git config --global alias.st "status"
git config --global alias.co "checkout"  
git config --global alias.br "branch"
git config --global alias.ci "commit"
git config --global alias.cm "commit -m"
git config --global alias.lg "log --graph --oneline --all"
git config --global alias.unstage "reset HEAD --"
git config --global alias.last "log -1 HEAD"

别名的实际收益

效率对比

原始命令：git status
别名命令：git st
节省：4个字符 × 每天50次 = 200字符/天

我最爱的几个别名

git lg：图形化查看提交历史，分支关系一目了然
git cm：快速提交，git cm "feat: add feature"
git last：查看最近一次提交详情，快速确认刚刚提交的内容

进阶技巧：组合别名

你甚至可以创建复杂的组合命令：

# 一键推送并设置上游分支
git config --global alias.publish "push -u origin HEAD"

# 使用：git publish
# 等价于：git push -u origin HEAD

注意事项：别名的设置因人而异，建议根据你的使用习惯定制。刚开始可以从上面推荐的几个开始，逐渐添加。

🎯 第一阶段小结

现在你的Git环境已经配置完成：

✅ 身份信息已设置（不再是"unknown"）
✅ 编辑器配置完成（告别vim挣扎）
✅ 别名设置就绪（提升输入效率）
✅ 颜色显示开启（视觉化文件状态）

这些配置是一次性的投资，会在未来的所有项目中持续带来收益。现在，让我们进入真正的Git操作世界。

第二阶段：创建或加入项目 - 仓库的诞生

无论你是从零开始一个新项目，还是加入一个已有团队，Git仓库都是代码管理的起点。这一阶段将教你如何"创造"或"获取"一个Git仓库。

场景选择

个人项目：从本地初始化开始，逐步构建
团队项目：直接克隆远程仓库，快速上手
开源贡献：fork后克隆，开启开源之旅

2.1 从零开始：初始化本地仓库

这是Git最简单的命令，也是个人项目最常见的起点。git init 会在当前目录创建一个隐藏的 .git 文件夹，这里面存放了Git的所有版本控制信息。

# 标准流程：创建项目并初始化
mkdir my-blog         # 创建项目文件夹
cd my-blog            # 进入项目目录
git init              # 初始化Git仓库

执行后你会看到：

Initialized empty Git repository in /path/to/my-blog/.git/

`.git`目录里有什么？

初始化后，当前目录下会生成一个隐藏的.git文件夹，包含：

config：仓库配置文件
HEAD：当前分支指针
objects/：存储所有Git对象（提交、文件内容等）
refs/：分支和标签的引用

最佳实践：先创建.gitignore

在初始化后立即创建.gitignore文件是个好习惯，避免不小心提交了敏感信息或无关文件。

# 初始化后立即执行
echo "node_modules/" > .gitignore
echo ".env" >> .gitignore
echo "*.log" >> .gitignore

常见错误：在错误的位置执行git init。比如在用户根目录执行，会导致整个用户目录变成Git仓库。解决方法：删除.git文件夹即可。

2.2 加入团队：克隆远程仓库

这是参与团队开发或开源项目的标准入口。git clone 不仅复制代码，还会自动设置远程跟踪分支，让你可以立即开始协作。

# 克隆完整仓库（最常用）
git clone https://github.com/zhangsan/my-blog.git

# 克隆后进入项目目录
cd my-blog

克隆的魔法：背后发生了什么？

创建目录：自动创建my-blog文件夹
下载代码：复制所有文件到本地
初始化仓库：自动执行git init
添加远程：自动设置origin指向克隆地址
检出代码：自动切换到默认分支（通常是main）

克隆选项：按需定制

# 1. 只克隆特定分支（节省时间空间）
git clone -b dev https://github.com/zhangsan/my-blog.git

# 2. 指定目录名
git clone https://github.com/zhangsan/my-blog.git blog-project

# 3. 深度克隆（只获取最近n次提交）
git clone --depth 1 https://github.com/zhangsan/my-blog.git

# 4. 递归克隆（包含子模块）
git clone --recursive https://github.com/zhangsan/my-blog.git

实际场景选择

场景	推荐命令	说明
日常开发	`git clone <url>`	完整克隆，便于查看历史
快速查看	`git clone --depth 1 <url>`	只克隆最新代码，速度快
大仓库	`git clone -b main --single-branch <url>`	只克隆主分支，节省空间
包含子模块	`git clone --recursive <url>`	递归克隆所有依赖

克隆后的第一件事

# 查看远程配置
git remote -v

# 查看所有分支
git branch -a

# 查看项目状态
git status

常见问题：克隆速度慢怎么办？

使用SSH代替HTTPS：git clone git@github.com:zhangsan/my-blog.git
使用国内镜像（如Gitee）
使用--depth 1只克隆最新版本

🎯 第二阶段小结

现在你已经掌握了Git仓库的创建方式：

✅ 本地初始化：适合个人新项目
✅ 远程克隆：适合加入团队或开源项目
✅ 定制克隆：根据需求选择不同克隆选项

仓库只是容器，真正的价值在于里面的代码。接下来，让我们学习Git最核心的操作：如何管理代码改动。

第三阶段：Git的日常工作流 - 修改、暂存、提交

这是你每天都会用到的Git核心操作，也是版本控制的精髓所在。理解这三个步骤，就理解了Git 80%的功能。

Git的三个工作区域

在深入学习命令前，先理解Git的三个关键区域：

工作区：你正在编辑的代码文件
暂存区：准备提交的改动（临时存放区）
仓库区：永久保存的版本历史

工作流程：修改代码 → 暂存改动 → 提交版本

3.1 查看状态：随时掌握代码变化

git status 是你最应该频繁使用的Git命令。它像代码的"仪表盘"，实时显示哪些文件被修改、添加或删除。

# 完整状态查看（推荐新手使用）
git status

# 精简状态查看（推荐熟练后使用）
git status -s

状态解读指南

完整状态输出示例：

On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
  new file:   index.html       # 绿色：已暂存的新文件

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  modified:   style.css        # 红色：已修改但未暂存

Untracked files:
  (use "git add <file>..." to include in what will be committed)
  README.md                    # 红色：未跟踪的新文件

精简状态输出示例：

A  index.html    # A: Added (已暂存的新文件)
 M style.css     # M: Modified (已修改未暂存)
?? README.md     # ??: Untracked (未跟踪文件)

状态标记详解

(空格)：无变化
M：文件被修改
A：新增文件（已暂存）
D：文件被删除
R：文件被重命名
C：文件被复制
U：文件冲突未解决
??：未跟踪的新文件

使用技巧

# 别名：gs（如果你设置了别名）
git gs

# 结合其他命令
git status && git diff  # 先看状态，再看具体修改

# 只关注特定类型文件
git status | grep -E "(modified|deleted)"  # 只看修改和删除

最佳实践：在每次git add或git commit前都先执行git status，确认你要操作的文件是正确的。

3.2 暂存改动：精细化控制提交内容

暂存区是Git的独特设计，它让你可以选择性提交。你可以只提交部分文件的改动，甚至只提交一个文件中的部分修改。

# 1. 暂存单个文件（精准控制）
git add index.html

# 2. 暂存所有改动（最常用）
git add .

# 3. 暂存所有修改（不包括新文件）
git add -u

# 4. 交互式暂存（高级功能）
git add -p

不同暂存策略的应用场景

场景一：修复bug并添加新功能

# 错误做法：一次性提交所有改动
git add . && git commit -m "修复bug并添加功能"

# 正确做法：分开提交
git add bug-fix.js && git commit -m "fix: 修复登录验证bug"
git add new-feature.js && git commit -m "feat: 添加用户头像上传"

场景二：提交前审查自己的代码

# 先暂存所有改动
git add .

# 查看即将提交的内容
git diff --cached

# 如果发现不需要的修改，可以取消暂存
git reset HEAD unwanted-file.js

交互式暂存：代码审查级别的控制

git add -p 是Git最强大的功能之一，它让你可以逐块审查代码改动。

# 对特定文件进行交互式暂存
git add -p index.js

交互界面示例：

Stage this hunk [y,n,q,a,d,s,e,?]?

y：暂存当前块
n：不暂存当前块
s：将当前块拆分成更小的块
e：手动编辑当前块
?：查看帮助

使用场景：

分离关注点：把bug修复和新功能分开提交
清理调试代码：只提交业务逻辑，排除console.log
重构提交：将大改动拆分成逻辑清晰的小提交

暂存区的工作原理

暂存区就像一个"购物车"：

工作区的改动 = 货架上的商品
git add = 把商品放入购物车
git commit = 结账付款
你可以随时从购物车取出商品（git reset HEAD）

最佳实践：每次提交前，用git diff --cached检查暂存区的内容，确保提交的都是相关改动。

3.3 提交代码：为你的工作留下清晰的历史记录

提交是Git的核心操作，它不仅仅是保存代码，更是为你的工作创建可追溯的历史记录。一个好的提交应该像一篇好的日记：清晰、有意义、便于日后查阅。

# 1. 标准提交（推荐使用）
git commit -m "feat: 完成首页响应式布局"

# 2. 一步提交（快捷方式）
git commit -am "fix: 修复移动端样式错位"

# 3. 修改上次提交
git commit --amend -m "feat: 完成首页布局并优化图片加载"

# 4. 追加文件到上次提交
git commit --amend --no-edit

# 5. 空提交（特殊用途）
git commit --allow-empty -m "ci: 触发CI/CD流水线"

提交信息的艺术：写好"为什么"而不仅仅是"做了什么"

差的提交信息：

git commit -m "更新代码"
git commit -m "修复bug"
git commit -m "添加功能"

好的提交信息：

git commit -m "feat(auth): 添加微信扫码登录功能"
git commit -m "fix(api): 解决跨域请求被浏览器拦截问题"
git commit -m "docs: 更新API接口文档，补充错误码说明"

提交类型详解

标准提交流程：

# 查看状态
git status

# 暂存改动
git add .

# 提交代码
git commit -m "feat: 添加用户个人中心页面"

一步提交的局限性：

# 注意：git commit -am 只能提交已跟踪文件的修改
# 对于新增文件，仍需先使用 git add
git commit -am "fix: 修复已知问题"  # ❌ 不会提交新文件
git add . && git commit -m "fix: 修复已知问题"  # ✅ 正确做法

提交修正：优雅地修改历史

git commit --amend 是Git中最实用的功能之一，但需要谨慎使用。

适用场景：

写错提交信息：立即修正，保持历史整洁
遗漏文件：将忘记暂存的文件加入上次提交
合并小提交：将多个小改动合并为一个逻辑完整的提交

使用示例：

# 场景：提交后发现有typo
git commit -m "feat: 添加上传功能"
# 发现拼写错误，立即修正
git commit --amend -m "feat: 添加文件上传功能"

# 场景：提交后想起忘记添加某个文件
git add missed-file.js
git commit --amend --no-edit

重要提醒：--amend 只适用于尚未推送到远程的提交。如果已经推送，需要使用其他方法。

空提交的特殊用途

空提交不包含代码改动，但有以下实际用途：

触发自动化流程：CI/CD、自动部署
标记里程碑：记录重要时间节点
测试工作流：验证提交钩子是否正常工作

# 触发GitHub Actions
git commit --allow-empty -m "ci: 触发生产环境部署"
git push origin main

提交的最佳实践

原子性提交：每个提交只做一件事，便于回退和代码审查
描述性信息：说明"为什么"修改，而不只是"修改了什么"
遵循规范：使用约定式提交规范，让历史更可读
及时提交：完成一个小功能就提交，避免积累大量改动
本地验证：提交前运行测试，确保不破坏现有功能

记住：提交历史是你的开发日志，也是团队协作的基础。花时间写好提交信息，未来你会感谢自己的。

阶段4 分支基础：单人开发分支管理（隔离开发）

核心：分支 = 独立开发环境，改功能不影响主代码。

4.1 查看分支

查看本地分支：git branch —— 当前所在分支前有 * 标记。
查看远程分支：git branch -r —— 列出远程仓库的所有分支。
查看所有分支（本地+远程）：git branch -a。
查看分支最新提交：git branch -v —— 显示每个分支的最后一次提交哈希和说明。
查看跟踪关系及落后/领先状态：git branch -vv。

4.2 创建分支

仅新建分支：git branch feature/login —— 在当前提交上创建 feature/login 分支，但不切换过去。
基于历史提交创建分支：git branch bugfix 123456 —— 从指定提交哈希处创建分支，常用于修复旧版本 bug。
新建并切换（传统写法）：git checkout -b feature/login。
新建并切换（新版推荐）：git switch -c feature/login —— 语义更清晰，Git 2.23+ 可用。

4.3 切换分支

传统切换：git checkout main —— 切换到主分支。
新版切换：git switch feature/login —— 推荐使用。
快速切回上一分支：git checkout - —— 在多个分支间快速往返。

阶段5 远程协作：关联/拉取/推送（团队同步代码）

核心：本地代码 ↔ 远程 GitHub 仓库，多人共享。

5.1 远程仓库管理

查看远程地址：git remote -v —— 显示当前仓库绑定的远程仓库地址及权限（fetch/push）。
添加远程仓库：git remote add origin https://github.com/zhangsan/my-blog.git —— 将本地仓库与远程仓库关联，origin 是默认名称。
修改远程地址：git remote set-url origin https://gitee.com/zhangsan/my-blog.git —— 更换托管平台时使用。
重命名远程仓库：git remote rename origin upstream —— 当你需要同时追踪多个远程仓库时很有用。
移除远程仓库绑定：git remote remove origin。

5.2 推送代码（本地 → 远程）

推送指定分支：git push origin feature/login —— 将本地 feature/login 分支推送到远程。
首次推送并建立跟踪：git push -u origin main —— 之后在该分支下只需执行 git push 即可。
推送所有本地分支：git push --all origin。
推送所有标签：git push --tags origin。
强制推送（危险）：git push --force origin feature/login —— 仅在个人独占分支上使用，会覆盖远程历史。
更安全的强制推送：git push --force-with-lease origin feature/login —— 如果远程分支有新提交则拒绝推送，避免覆盖他人工作。

5.3 拉取代码（远程 → 本地）

仅拉取不合并：git fetch —— 将远程最新提交下载到本地仓库，但不改动工作区，安全查看变化。
拉取所有远程仓库：git fetch --all。
拉取并自动合并：git pull —— 等于 git fetch + git merge。
拉取指定分支并合并：git pull origin main —— 将远程 main 分支合并到当前分支。
拉取并变基：git pull --rebase —— 拉取后使用变基方式合并，保持提交历史线性整洁。

阶段6 分支进阶：合并/删除（功能完成，合并上线）

核心：功能开发完 → 合并到主分支 → 清理无用分支。

6.1 合并分支

普通合并：git merge feature/login —— 将 feature/login 分支合并到当前分支（默认可能使用快进合并）。
仅允许快进合并：git merge --ff-only feature/login —— 如果无法快进（有分叉）则直接失败，避免意外合并。
强制生成合并提交：git merge --no-ff feature/login —— 即使能快进也创建一个合并提交，保留分支开发痕迹，推荐用于主分支合并。
压缩合并：git merge --squash feature/login —— 将该分支所有提交压成一个变更集放入暂存区，需手动提交，历史更干净。
放弃合并：git merge --abort —— 合并过程中出现冲突时，放弃本次合并，回到合并前状态。

6.2 删除分支

安全删除本地分支：git branch -d feature/login —— 只有该分支的改动已被合并时才允许删除。
强制删除本地分支：git branch -D feature/test —— 未合并也要删除，用于废弃功能。
删除远程分支：git push origin --delete feature/login —— 清理远程仓库中已不需要的分支。

阶段7 排错核心：撤销&回退（改坏代码一键恢复）

核心：开发必学，覆盖工作区/暂存区/提交记录全场景。

7.1 撤销暂存区（add 错了，撤回暂存）

撤销单个文件暂存：git reset HEAD index.html —— 文件改动保留在工作区。
撤销所有暂存：git reset HEAD —— 将所有暂存文件移回工作区。
新版命令：git restore --staged index.html —— Git 2.23+ 推荐，语义更明确。

7.2 撤销工作区（改乱代码，丢弃修改）

丢弃单个文件修改：git checkout -- index.html —— 用仓库中的最新版本覆盖工作区文件，修改将永久丢失。
丢弃所有文件修改：git checkout -- . —— 极度危险，请确认无误再执行。
新版命令：git restore index.html —— 推荐使用。

7.3 回退提交（commit 错了，撤销版本）

软回退：git reset --soft HEAD~1 —— 撤销最近一次提交，改动保留在暂存区，可重新编辑提交信息再次提交。
混合回退（默认）：git reset --mixed HEAD~1 —— 撤销提交，改动保留在工作区（未暂存状态）。
硬回退（危险）：git reset --hard HEAD~1 —— 彻底删除最近一次提交及所有相关改动，仅限本地测试环境使用。
回退到指定历史版本：git reset --hard 123456 —— 丢弃该提交之后的所有改动。

7.4 反向提交（远程代码改错，安全撤销）

区别于 reset：不删除历史，而是生成一个新的反向提交来撤销改动，团队协作专用。

撤销单次提交：git revert 123456 —— 自动打开编辑器编写新提交说明，提交后原提交的改动被抵消。
撤销合并提交：git revert -m 1 789abc —— 撤销一次合并操作，需指定保留哪一边的代码（-m 1 通常指保留主分支）。
批量撤销连续提交：git revert 123456..789abc —— 会依次为每个提交生成反向提交。
放弃正在进行的 revert：git revert --abort。

7.5 🆕 时光机恢复：引用日志（找回丢失的提交）

git reflog 记录了本地仓库所有 HEAD 移动历史，即使提交被 reset --hard 删除、分支被删除，只要在本地，90 天内都可找回。

查看所有操作记录：git reflog —— 输出形如 HEAD@{0}、HEAD@{1} 的索引。
查看特定分支记录：git reflog feature/login。
临时切换到历史状态：git checkout HEAD@{2} —— 进入“游离 HEAD”状态，可查看丢失代码。
永久恢复到历史状态：git reset --hard HEAD@{2} —— 丢失的提交瞬间找回。

阶段8 临时操作：代码暂存（中途切分支，保存未完成代码）

核心：写了一半代码，突然要切分支修 bug，暂存临时改动。

暂存所有修改：git stash —— 工作区和暂存区的改动被保存，工作区恢复干净。
包含未跟踪文件：git stash -u —— 连新建但未 add 的文件一起暂存。
添加备注信息：git stash save "登录功能开发中" —— 便于区分多个暂存记录。
查看暂存列表：git stash list —— 显示所有暂存记录，如 stash@{0}。
恢复最近暂存并删除记录：git stash pop —— 等价于 git stash apply + git stash drop。
恢复指定暂存且保留记录：git stash apply stash@{0} —— 可多次应用到不同分支。
删除指定暂存：git stash drop stash@{0}。
清空所有暂存：git stash clear。
查看暂存具体内容：git stash show -p stash@{0}。

阶段9 日志排查：查看历史&对比差异（找 bug / 查改动）

核心：谁改了代码、改了什么、什么时候改的，一键查询。

9.1 查看提交历史

完整历史：git log —— 按时间倒序列出提交哈希、作者、日期、说明。
单行精简显示：git log --oneline。
图形化分支路线：git log --graph --oneline —— 清晰看到分支分叉与合并。
查看所有分支图形：git log --graph --all --oneline。
查看特定文件历史：git log -- index.html。
按作者过滤：git log --author="zhangsan"。
按时间范围过滤：git log --since="2024-01-01" --until="2024-12-31"。
按提交说明关键词搜索：git log --grep="登录"。

9.2 查看提交详情

查看某次提交改动内容：git show 123456。
查看最近一次提交：git show HEAD。
只看改动统计：git show --stat 123456 —— 显示哪些文件被修改、增删行数。

9.3 代码差异对比

工作区 vs 暂存区：git diff —— 还未 add 的修改。
暂存区 vs 上次提交：git diff --cached —— 即将被提交的内容。
工作区 vs 最新提交：git diff HEAD —— 包含所有未提交的改动。
两个历史版本对比：git diff 123456 789abc。
两个分支对比：git diff main dev。
单个文件对比：git diff index.html。
按单词粒度对比：git diff --word-diff —— 行内修改高亮更精准。

9.4 精准定位问题

全局代码搜索：git grep "password" —— 在仓库所有文件中搜索关键词。
带行号搜索：git grep -n "TODO" —— 快速定位所有待办注释。
逐行归属查询：git blame index.html —— 显示每一行代码是谁、在哪次提交中引入的。
指定行范围查询：git blame -L 10,20 index.js。
二分法定位 bug 引入提交：
1. git bisect start
2. git bisect bad —— 标记当前版本有 bug。
3. git bisect good 123456 —— 标记一个已知正常的版本。
4. Git 会自动切换到中间提交，测试后标记 good 或 bad，重复直至找到第一个坏提交。

🆕 阶段10 标签管理：版本发布与里程碑

核心：为重要提交打标签，标记版本节点（v1.0.0），方便回溯和发布。

10.1 查看标签

列出所有标签：git tag。
通配符过滤：git tag -l "v1.*" —— 只看 v1.x 系列版本。
查看标签详情：git show v1.0.0 —— 显示标签对应的提交信息和代码。

10.2 创建标签

轻量标签：git tag v1.0.0 —— 只是一个指向提交的指针，不含额外信息。
附注标签（推荐）：git tag -a v1.0.0 -m "正式发布博客v1.0" —— 包含打标签者、日期、说明，推荐用于版本发布。
为历史提交补打标签：git tag -a v0.9.0 123456 -m "内测版本"。

10.3 推送标签到远程

推送单个标签：git push origin v1.0.0。
推送所有本地标签：git push origin --tags。
删除远程标签：git push origin --delete v1.0.0。

10.4 删除本地标签

删除指定标签：git tag -d v1.0.0。
删除所有本地标签（谨慎）：git tag -d $(git tag -l)。

🆕 阶段11 进阶协作技巧：rebase / cherry-pick / clean

核心：让提交历史更整洁、灵活选取提交、清理工作区垃圾。

11.1 变基操作（rebase）—— 让提交历史成直线

场景：功能分支开发时，主分支已有新提交。用 rebase 代替 merge 可保持历史线形、干净。

将当前分支变基到目标分支：git rebase main —— 把当前分支的提交“接”到 main 分支最新节点之后。
交互式变基（整理历史）：git rebase -i HEAD~3 —— 对最近 3 次提交进行合并、修改说明、删除等操作。
解决冲突后继续：git add . && git rebase --continue。
放弃变基：git rebase --abort。

📌 rebase 黄金法则：永远不要对已推送到远程的公共分支执行 rebase！ 否则会彻底扰乱协作者的提交历史。

11.2 挑拣提交（cherry-pick）—— 搬砖专用

场景：只想把某个分支的单个或几个提交应用到当前分支，而不合并整个分支。

挑拣单个提交：git cherry-pick 123456 —— 将该提交的改动复制到当前分支，生成新提交。
挑拣多个提交：git cherry-pick 123abc 456def。
挑拣连续范围：git cherry-pick 123456..789abc —— 不包括起始提交。
解决冲突后继续：git cherry-pick --continue。
放弃挑拣：git cherry-pick --abort。

11.3 清理未跟踪文件（clean）—— 还你干净工作区

演习模式（安全第一）：git clean -n —— 仅显示将要删除的未跟踪文件，不实际删除。
强制删除文件：git clean -f。
同时删除文件夹：git clean -fd。
连 .gitignore 忽略的文件也删：git clean -fx。

阶段12 全流程实战：项目开发完整闭环（照搬即用）

覆盖新建项目 → 功能开发 → 合并上线 → 紧急修复 → 版本发布全场景，1:1 适配企业开发。

12.1 新项目初始化（从零到远程）

# 1. 创建项目并初始化
mkdir my-blog && cd my-blog
git init

# 2. 配置忽略文件（node_modules、日志等不上传）
echo "node_modules/" > .gitignore
echo ".env" >> .gitignore

# 3. 新建文件并首次提交
echo "# 个人博客" > README.md
git add .
git commit -m "init: 项目初始化，新增基础文件"

# 4. 绑定远程仓库并推送
git remote add origin https://github.com/zhangsan/my-blog.git
git push -u origin main

12.2 常规功能开发（分支开发 → 合并上线）

# 1. 拉取主分支最新代码
git switch main && git pull

# 2. 新建功能分支开发
git switch -c feature/login

# 3. 开发代码 → 暂存 → 提交
git add . && git commit -m "feat: 完成账号登录功能"

# 4. 同步主分支代码，解决冲突（推荐变基）
git fetch origin
git rebase origin/main
# （如有冲突，解决后执行 git add . && git rebase --continue）

# 5. 推送分支到远程，提交 PR 审核
git push origin feature/login

# 6. 审核通过，合并到主分支并推送
git switch main && git pull
git merge --no-ff feature/login -m "merge: 合并登录功能"
git push origin main

# 7. 清理无用分支
git branch -d feature/login
git push origin --delete feature/login

12.3 线上紧急 bug 修复（热修复流程）

# 1. 切主分支，拉取最新线上代码
git switch main && git pull

# 2. 新建热修复分支
git switch -c hotfix/login-bug

# 3. 修复 bug → 快速提交
git add . && git commit -m "fix: 修复登录密码错误bug"

# 4. 合并到主分支，推送上线
git switch main && git merge --no-ff hotfix/login-bug -m "hotfix: 登录bug修复"
git push origin main

# 5. 同步到开发分支，清理分支
git switch dev && git merge hotfix/login-bug
git push origin dev
git branch -D hotfix/login-bug

# 6. 打版本标签，记录上线版本
git tag -a v1.0.1 -m "修复登录bug"
git push origin v1.0.1

12.4 🆕 挑拣特定功能到发布分支

# 场景：dev分支有多个功能，现在只需要发布其中“文章评论”功能到 main
git switch main && git pull
git cherry-pick 3a5f7b1 8c2d4e6   # 挑拣评论功能相关的两个提交
# 解决可能冲突后
git push origin main

🆕 阶段13 协同工作流简介（团队规范参考）

不同团队规模和发布节奏适用不同的 Git 工作流：

Git Flow：分支结构严格，包含 main、develop、feature、release、hotfix 等多类分支。适合版本发布周期长、需严格质量管控的传统软件项目。
GitHub Flow：极其简洁，仅 main 主分支 + 功能分支，所有改动通过 Pull Request 合并。适合持续部署的 Web 应用和敏捷团队。
GitLab Flow：在 GitHub Flow 基础上增加环境分支（如 staging、production），与 main 联动，适合多环境部署场景（测试、预发、生产）。

小型团队或个人项目建议直接使用 GitHub Flow：主分支保护，所有改动通过分支 + PR 进行，简单高效。

补充：高频清理 & 优化命令

清理无效远程分支引用：git remote prune origin —— 远程分支已被删除，但本地仍显示 origin/xxx，执行后清理干净。
垃圾回收优化仓库：git gc --auto —— Git 自动整理松散对象，提升性能。
检查仓库完整性：git fsck —— 诊断仓库对象是否损坏。