feature分支必须从develop拉取，不能基于master；release分支是冻结分支，仅允许bugfix；hotfix需同时合并至master和develop；feature分支生命周期应≤1周。

feature 分支必须从 develop 拉取，不能直接基于 master

很多团队在刚切 feature 分支时习惯性执行 git checkout -b feature/login master，结果导致新功能代码缺失 develop 中已合入但尚未发布的改动，上线前才发现依赖不全或接口不一致。develop 是所有待发布功能的集成基线，feature 必须从中拉取，才能保证环境一致性。

• 正确做法：git checkout develop && git pull && git checkout -b feature/user-login
• CI 流水线通常只监听 develop 和 feature/* 分支，如果 feature 基于 master，自动构建可能跳过依赖检查
• 命名要带上下文，比如 feature/user-login-v2，避免和已有 feature/user-login 冲突
• 切完分支立刻提交一次空 commit（git commit --allow-empty -m"init feature branch"）并 push，方便后续 PR 关联和权限审计

release 分支不是“测试分支”，而是“冻结分支”

常见误解是把 release/v2.1.0 当作日常提测环境，持续往里合新功能——这会破坏版本边界。release 分支一旦创建，只允许合入 bugfix，不允许新增逻辑、改接口、增字段。它的核心作用是固化当前候选版本，为 QA 和灰度提供稳定基线。

• 创建时机：develop 中功能全部合入、冒烟通过后，执行 git checkout -b release/v2.1.0 develop
• 合入限制：仅允许 hotfix/ 类分支或针对该 release 的小范围修复 PR，且需组长审批
• 生命周期短：上线后立即合并回 master 和 develop，然后删除远程分支（git push origin --delete release/v2.1.0）
• 标签打在 merge commit 上，不是最后那个 fix 提交，否则 tag 指向不稳定

hotfix 必须同时合并到 master 和 develop，漏掉 develop 就埋雷

线上紧急修复常被快速处理，但开发者容易只关注 master 合并，忘了同步回 develop。后果是：下个迭代的 develop 里没有这个修复，新功能开发中复现相同问题，或者更糟——修复被覆盖回滚。

MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub

使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...

下载

• 标准流程：git checkout master && git pull && git checkout -b hotfix/auth-token-expire → 修复 → git checkout master && git merge --no-ff hotfix/auth-token-expire → git checkout develop && git merge --no-ff hotfix/auth-token-expire
• 合并到 develop 时若出现冲突，说明 develop 已有相关逻辑变更，必须人工介入比对，不能简单跳过
• hotfix 分支名建议含版本号，如 hotfix/v2.0.5-auth-token-expire，便于追溯影响范围
• 自动化脚本可配置 pre-merge hook，检查 hotfix 是否已存在于 develop 的 commit history 中

feature 分支长期不合并，比 merge conflict 更危险

一个存活超过 3 周的 feature/user-profile-redesign 分支，即使没冲突，也意味着它脱离了主干演进节奏。API 变更、工具链升级、安全补丁都可能让它上线时失败——这不是 Git 能解决的问题，是流程失控的信号。

• 团队应设定硬性规则：feature 分支生命周期 ≤ 1 周（敏捷迭代周期内必须闭环）
• 每日 git rebase develop 或 git merge develop 至少一次，暴露集成风险而非堆到最后
• CI 配置可加分支存活时长告警，例如 GitHub Actions 检查 git log -n1 --since="7 days ago" feature/*
• 如果功能太大无法拆，说明设计有问题，得先重构再分拆，而不是容忍长命分支

真正难的不是记住分支命名规则，而是让每个成员在赶进度时仍坚持拉取 develop、在 hotfix 合并后多敲一行命令切到 develop 再 merge——这些动作不产生业务价值，却决定着下次上线会不会凌晨三点被 call 起来救火。