分支与协作流
Git 分支策略决定团队怎么协作。Git Flow（开发/测试/发布多条长期分支）最严谨但也最重；GitHub Flow（main + 功能分支，PR 合并）简单可靠，是中小团队主流；Trunk-based（所有人频繁往主干推，短命分支）适合 CI 成熟、追求持续部署的团队。
分支规范的关键不是选哪套，而是“约定清晰”：功能分支命名 feat/xxx、修复分支 fix/xxx、发布分支 release/x.y，合并前必须 PR 评审 + CI 通过。
- GitHub Flow：main 受保护，功能分支 → PR 评审 → 合并，最常用
- 分支命名约定：feat/ fix/ hotfix/ release/ 加简短描述
- 合并前跑 CI（lint + test + build），失败禁止合并——质量靠流程而非觉悟
Git
// 日常协作的标准动作（命令行） // 1. 从最新的 main 切功能分支 // git checkout main && git pull && git checkout -b feat/user-login // 2. 小步提交，频繁同步 // git add . && git commit -m "feat(login): 添加登录表单校验" // git push origin feat/user-login // 3. 平息“远程有新提交”的冲突：变基而非合并，历史更干净 // git pull --rebase origin main // 4. 发起 PR → 评审 → CI 全绿 → 合并（推荐 squash 合并，历史一条线） // git merge --squash feat/user-login // 分支生命周期要短：一个功能分支最好 1~3 天内合并，降低冲突概率
本节要点中小团队首选 GitHub Flow：保护分支 + 功能分支 + PR 评审 + CI 卡关。
