Modern Git 进阶全攻略
入门
本章适合已经会用 git add、git commit，但还没形成稳定协作规范的大学生。读完这一章，你应该能看懂团队为什么坚持 main 保护分支、为什么要统一提交信息，以及 merge 和 rebase 分别适合什么场景。
你将学会什么
Section titled “你将学会什么”- 建立稳定的日常提交习惯
- 理解分支策略背后的协作原因
- 学会最小可用的提交信息规范
- 掌握冲突前的预防与冲突后的恢复顺序
- 会用
git add、git commit、git push - 有一个可以练习的本地仓库（没有的话，第一章会带你初始化一个）
| 章节 | 内容 |
|---|---|
| 1. 工作区、暂存区与提交历史 | Git 核心数据结构与日常提交流程 |
| 2. 分支策略与命名 | main 保护分支、feature/fix 分支与合并约定 |
| 3. 提交信息规范 | 最小可用模板 <type>(<scope>): <subject> |
| 4. merge 与 rebase 的选用 | 两种合并方式的适用场景与协作信任 |
| 5. 问题排查与现场保留 | 四个排查命令与 stash 保存现场 |
| 6. 撤销与恢复 | reset、revert 与 cherry-pick 的适用边界 |
| 7. 标签与提交卫生 | tag 里程碑与 .gitignore |
| 8. 把规范用起来 | 学生项目完整工作流与进阶路线 |
学习路线建议
Section titled “学习路线建议”- 如果你目前只会最基础的 Git 命令，建议按「理解
HEAD、ref和origin→ 学会看分支图 → 练习cherry-pick和revert→ 在真实项目坚持两周」的顺序补强 - 每章末尾都有 3 道小测验，答错时解析会说明原因
merge 和 rebase 到底该用哪个？
Section titled “merge 和 rebase 到底该用哪个？”看你的提交是否已经推送到远端。本地只有你一个人时，用 rebase 把提交整理成一条线性历史；提交已推送、且其他人可能基于该分支继续工作时，改用 merge 保留完整历史。拿不准时选 merge，协作信任比历史美观更重要。详见 merge 与 rebase 的选用。
为什么 main 分支不能直接提交？
Section titled “为什么 main 分支不能直接提交？”main 是团队协作的稳定基线，所有人都直接在上面提交，「哪版是可运行版本」会变得不可控。新功能、修复应分别开 feature/、fix/ 分支，每个分支只做一类变更，便于评审和回滚；合并前先运行 git status 确认没有未提交的改动。详见 分支策略与命名。
提交信息写到什么程度才算合格？
Section titled “提交信息写到什么程度才算合格？”套用最小可用模板 <type>(<scope>): <subject>，说明意图而不是复述 diff。feat(quiz): 新增错题回顾功能 说明「做了什么」，update file 则等于没说。统一规范后，扫一眼 git log 就能还原项目演进。详见 提交信息规范。
已经推送到远端的提交还能 rebase 吗？
Section titled “已经推送到远端的提交还能 rebase 吗？”不建议。rebase 会改写提交记录，如果队友已经基于该分支继续开发，强制推送会打乱他们的本地分支。共享分支合回主分支时用 merge 更安全，它不改写历史。详见 merge 与 rebase 的选用。
- Git 官方文档—— 全部命令的权威参考与手册索引
- Pro Git 中文版—— 官方书籍，系统讲解分支、合并与变基
- 变基（Pro Git 第 3.6 节）—— 官方对 rebase 风险与适用场景的完整说明
- 约定式提交规范—— 提交信息 type 约定的通用标准