Git分支本质是轻量级指针，所有分支天生轻量；所谓“重量级”实为人为维护不当所致，如长期存在、大量偏离主干、频繁rebase或未同步合并，导致协作混乱与维护成本上升。
轻量级分支不是一种策略，而是 Git 的默认行为
Git 里根本没有“重量级分支”这个东西——所有分支都是轻量级的，本质只是指向某个 commit 的指针。所谓“重量级分支”的错觉，通常来自人为长期维护、大量未合入提交、频繁 rebase 或 cherry-pick 的分支，导致它在逻辑上变得臃肿，而不是 Git 本身让它变重。
你看到的“分支很重”，实际是以下情况叠加的结果：
- 分支存在时间过长（比如超过两周没合并）
- 该分支上积累了大量与主干 diverged 的提交
- 团队习惯在分支上反复
rebase而非merge，造成历史重写和协作混乱 - CI/CD 流水线为每个分支单独构建镜像或部署环境，资源开销被误认为“分支重”
什么时候该避免创建长期功能分支
长期功能分支（如 feature/user-auth-2025 持续存在一个月以上）是轻量级机制被用错的典型场景。它不违反 Git 规则，但会引发真实协作问题：
- 每次
git merge develop都可能带入大量冲突，尤其当多人同时改同一文件时 -
git diff feature..develop输出越来越难读，Code Review 成本陡增 - 自动化测试覆盖的是孤立分支状态，而非集成后的真实行为
- 分支命名容易泛滥：
feature/user-auth-v2、feature/user-auth-fix、feature/user-auth-final……
真正该做的是：把大功能拆成可独立交付的小变更，每项都基于最新 main 开分支、当天合入、当天验证。不是“别用分支”，而是“别让分支活着太久”。
GitFlow 里的 release/hotfix 分支不是“重量级”，但容易变成事实上的重量级
release/1.2 和 hotfix/1.1.3 这类分支在 GitFlow 中有明确定义，它们本身仍是轻量指针，但实践中常因以下操作失去轻量性：
- 在
release/1.2上修复 bug 后，只合入main，却忘了同步回develop→ 导致下次发版又得修一遍 -
hotfix分支从main切出，修复后合并回main和develop，但有人漏掉develop→ 引入隐性回归 - 为兼容旧版本，在
release/1.2上加条件编译或 feature flag，代码逻辑开始分叉
这些操作不会让 Git 多占空间，但会让分支承载的语义变重、维护成本变高。关键不是禁用这些分支，而是强制约定：所有 hotfix 必须双合入，所有 release 分支生命周期不超过 3 天，否则自动废弃。
判断分支是否“过载”的三个信号
不用看分支名或创建时间，直接运行这几条命令就能发现隐患：
-
git log --oneline feature/login | wc -l> 20 → 提交数过多，说明没及时拆解或合入 -
git merge-base feature/login main返回的 commit 距mainHEAD 已超 50 个提交 → 基线太老，合并风险高 -
git diff feature/login...main --stat显示修改了 15+ 文件且含核心模块 → 不再是单一功能，已变成“功能集”
一旦触发任一信号，就该暂停开发，先做一次 git rebase -i main 整理提交粒度，再拆成多个 PR 合入。轻量级分支的价值，不在“建得多”，而在“活得短、合得勤”。
