必须在git init后立刻设置分支模板，否则Gitee/GitLab的分支保护、CI触发、PR模板均失效，导致协作混乱；需同步配置平台规则、更新CI脚本、验证命名匹配。
团队初始化项目时，不提前定义分支模板，后续协作必然踩坑——尤其在 Gitee/GitLab 上，分支保护规则、CI 触发逻辑、PR 模板都依赖明确的分支命名和结构。
为什么必须在 git init 后立刻设置分支模板？
不是“可选动作”，而是防止后续所有人凭直觉乱建分支的底线。Gitee 和 GitLab 的分支保护规则（比如禁止直接 push 到 main）只对匹配命名规则的分支生效；CI 流水线也常靠分支名决定是否运行测试或构建。如果初期没统一，等 3 个人各自推了 dev、develop、dev-branch，后面连合并目标都难确认。
- 分支保护规则需提前在平台后台配置，且只对已存在的分支名模式生效（如
feature/*），不是“推了再配” - GitLab CI 的
.gitlab-ci.yml中only: [branches]或rules:都依赖分支名匹配，命名不规范会导致流水线漏触发 - Gitee 的 PR 模板默认绑定
main→develop或feature/*→develop，分支不存在或命名不符，模板不显示
git branch -m 重命名初始分支前必须做三件事
很多团队直接 git branch -m master main，但平台侧可能仍沿用旧名逻辑，导致保护规则失效或 CI 不识别。
- 先在 Gitee/GitLab 后台将默认分支设为
main（非仅本地改名） - 执行
git branch -m master main后，立即git push -u origin main，并手动删除远程旧分支：git push origin --delete master - 检查所有 CI 配置文件中是否硬编码了
master（如except: [master]），替换成main或改用正则匹配
功能分支创建时 git checkout -b 的参数陷阱
看似简单，但少传一个参数就可能偏离模板。正确姿势是始终基于最新 develop 创建，而非当前所在分支。
- 错误示范：
git checkout -b feature/login—— 若当前在main上，新分支基点错，后续 merge 会带入不该有的提交 - 正确流程：先
git checkout develop && git pull origin develop，再git checkout -b feature/login - 建议把常用分支创建封装成 alias：
git config --global alias.nb '!f() { git checkout develop && git pull origin develop && git checkout -b "feature/$1"; }; f'，之后直接git nb user-profile
分支模板落地后最容易被忽略的验证点
模板写了不等于生效。真正卡住协作的是平台侧配置与本地行为的断层。
- 在 Gitee 后台检查「分支保护规则」是否已启用，且规则覆盖
main、develop、release/*等全部预设类型 - 推一个
feature/test分支，看是否自动触发 CI（若没触发，大概率是.gitlab-ci.yml或.gitee/workflow中only条件写死了master） - 发起 PR 时，观察标题是否自动填充模板（如「feat: 登录页UI重构」），若无，说明 Gitee 的 PR 模板未关联到
feature/*命名空间
分支模板不是文档里的一行字，是本地命令、平台配置、CI 脚本三方咬合的结果。任一环脱节，协作就会在某个周五下午三点突然卡住。
