项目初期必须在首次 git push 前确立分支骨架，master 须保持稳定可发布状态，所有开发须基于 develop 分支，feature 分支必须从 develop 创建，小项目前3个迭代无需 release/hotfix 分支，命名避免下划线与空格，并及时推送和 fetch 远程分支。
项目刚初始化时就乱建分支，后面八成要重头来过。初期分支结构不是“先随便起几个，以后再规范”，而是必须在第一次 git push 前就定好骨架。
为什么不能直接从 master 开发新功能
直接在 master 上提交代码，等于把未验证的逻辑、调试日志、半成品配置一股脑塞进生产基线。一旦 CI/CD 自动部署触发，线上立刻出问题。
-
master应该永远对应可随时发布的稳定状态，哪怕项目还没上线，这个契约也要立住 - 所有新功能、修复、实验性改动，都必须通过独立分支进入，否则后续无法追溯“谁改了什么”
- IDEA 或 VS Code 的 Git 面板里看到
master被频繁切换或出现 merge commit，基本说明分支策略已经失控
develop 分支是初期唯一允许合入的“开发集散地”
它不是可选配件，而是协作起点。没有 develop，feature/xxx 就失去统一上游，团队很快会陷入“你推你的、我推我的”状态。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 创建方式：先切到
master，拉最新，再执行git checkout -b develop，然后git push -u origin develop - 所有
feature/分支必须基于develop创建，而不是master—— 否则功能间互相看不到对方的依赖变更 -
develop本身不接受直接 commit，只接受merge --no-ff或rebase后的 fast-forward 合并
别急着加 release 和 hotfix 分支
小项目或 MVP 阶段，强行套用 Git Flow 的完整分支模型，只会增加操作负担，还容易因误操作导致历史污染。
- 前 3 个迭代内，用
develop → master直接发布完全够用；release/v1.0这类分支，等第一次正式提测再建不迟 -
hotfix/分支看似安全，但若没配套的 tag 管理和自动化测试兜底，反而会让紧急修复变成“先上线再说”的赌局 - 真正需要
hotfix的信号是：线上故障平均响应时间超过 15 分钟，且每次修复都涉及跨多个 feature 的兼容性判断
分支命名和远程同步最容易漏掉的两件事
名字起得再规范，不推送到远端或本地没 fetch，对协作毫无意义。很多“分支不见了”问题，根源都在这一步。
- 本地新建
feature/login后，必须立刻执行git push -u origin feature/login——-u参数绑定上游，否则下次git push会报错 - 队友新建分支后，你不能只靠 IDEA 右下角刷新，必须手动运行
git fetch origin，否则git branch -r看不到新分支，IDE 也无法 checkout - 分支名里避免使用下划线
_或空格，Git 对路径解析敏感，某些 CI 工具（如 Jenkins Pipeline）会把feature/user_auth当作两个参数处理
初期结构搭得越轻，后期越不容易被自己绊倒。真正难的不是记住五种分支类型，而是每天坚持让 develop 保持可构建、让每个 feature/ 提交前都 rebase 到最新 develop —— 这些动作不会自动发生，得靠人盯住。
