分支策略与命名
你将学会什么
Section titled “你将学会什么”- 说清「main 只放稳定代码」背后的协作原因
- 用最小命名法命名分支：
feature/*、fix/*、docs/*、chore/* - 知道什么情况下可以直接合并、什么情况下该先开 PR
团队最容易出问题的，是所有人都在 main 上直接提交。真正适合学生项目的规范是：
main只保留稳定、可运行的代码- 新功能、修复、课程作业分别开
feature/*、fix/* - 每个分支只做一类变更，便于评审和回滚
这个策略的实质不是“为了规范而规范”，而是降低多人协作时的心理负担。只要分支命名清楚，你甚至可以在提交信息里直接说明这版代码解决哪一道课程实验题。
好的分支命名本身就是文档。建议采用这套最小命名法：
feature/xxx：新功能或新作业模块fix/xxx：修 bug、补边界条件、改异常提示docs/xxx：只改 README、注释或教程说明chore/xxx：配置文件、依赖更新、脚本调整
合并时尽量遵守这些约定：
- 小修小补可以直接合并
- 较长功能分支先开 PR，让队友审一眼
- 合并前先运行基础命令检查，比如
git status和git log --oneline -5
先自己回答，再看答案：
- 为什么
main分支不应该直接提交？ fix/和chore/分支各适合什么变更？- 合并前为什么要先看
git status？
参考答案
main是协作的稳定基线，直接提交会让“哪版是可运行版本”变得不可控。fix/适合修 bug、补边界条件；chore/适合配置文件、依赖、脚本调整。- 确认没有未提交的改动或意外文件，避免把无关变更一起合进去。
main只放可运行版本，变更走独立分支- 分支命名本身就是文档：
feature/、fix/、docs/、chore/ - 合并前先检查状态，长功能分支先开 PR