hotfix分支必须从master拉取并双向合并至master和develop；命名统一为hotfix/前缀且版本号对齐latest tag；修复后立即打annotated tag并清理分支。
hotfix分支必须从master拉取，而不是develop
线上紧急Bug修复必须基于当前生产环境的真实状态，而master分支才是这个状态的唯一权威来源。如果从develop拉取hotfix分支，修复后合并回master，会导致develop缺失这次修复——后续功能开发可能重复引入相同问题。
正确操作是：
- 先确保本地
master已同步远程：git checkout master && git pull origin master - 再创建热修复分支：
git checkout -b hotfix/payment-failed - 修复、提交、测试通过后，**同时合并到两个分支**：
git checkout master && git merge --no-ff hotfix/payment-failed，然后git checkout develop && git merge --no-ff hotfix/payment-failed
漏掉向develop合并这一步，是团队协作中最常被忽略、也最易引发二次事故的操作。
feature分支生命周期要短，避免长期游离
一个feature/login分支存在超过两周，就大概率开始偏离develop主线：新提交不断涌入，冲突概率指数级上升，最后合并时变成“不敢点确认”的心理负担。
控制分支寿命的关键动作：
- 每日至少一次同步主干：
git checkout develop && git pull && git checkout feature/login && git rebase develop（注意：仅限未推送的本地分支） - 拒绝“大功能拆成小提交但不拆分支”的做法——功能模块可分阶段交付，就应拆成多个
feature/xxx分支 - CI流水线对
feature/*分支启用自动构建+基础单元测试，失败即阻断，避免带病合并
长期存在的feature分支本质是隐藏的技术债，它不会让开发变快，只会让集成变难。
全面审计 Tasks.md 和 Flatnotes 的一致性与准确性；以 GitHub (gh CLI) 为事实来源检测过时笔记/卡片及缺失链接，并生成报告及可选修复计划。
merge --no-ff 是保护历史可读性的底线操作
默认的快进合并（fast-forward）会把feature分支的提交直接“平铺”到develop上，丢失了“这是一个完整功能”的上下文。一旦出问题，你无法快速定位这个功能的起止范围，也无法原子性地回滚整个功能。
强制非快进合并的好处：
- 每次
git merge --no-ff feature/user-auth都会生成一个明确的合并提交，其信息天然包含功能边界 - 配合
git log --graph能清晰看到功能分支的“生长-合并”轨迹 - 在Git平台（GitHub/Gitee）上，该合并提交会自动关联PR/MR，保留审查记录和讨论上下文
把--no-ff写进团队.gitconfig全局配置里，比靠人提醒更可靠：git config --global merge.ff false。
删除已合并分支前，务必确认develop已同步该次合并
git branch -d feature/xxx看似安全，但它只检查本地是否已合并——如果你刚在CI平台点完Merge，但还没git pull，develop在你本地仍是旧状态，此时删分支等于丢掉那次合并的本地记录。
稳妥流程是：
- 在平台完成PR合并后，立刻执行：
git checkout develop && git pull origin develop - 再验证该功能是否已在
develop中：git log --oneline -n 10 | grep "user-auth" - 确认无误后，才运行
git branch -d feature/user-auth
分支删除不是收尾动作，而是同步完成后的清理动作；跳过同步直接删，会让本地仓库和远程状态逐渐脱节，最终导致git status长期显示“Your branch is behind 'origin/develop'”却不知从何追起。
