长期分支维护教程

分支存活时间越长，漂移、重复冲突和混乱的历史就越容易堆积。 我们的目标不是"永远不冲突"，而是让漂移可见、同步批量小、分支债务可控。

持续监控

分支存活时间主线漂移冲突热区

→定期同步 → 验证 → 偿还债务

目标

更小的冲突更清晰的历史更低的合并冲击

当团队直到最后才检查漂移时，长期分支就会变得危险。

为什么长期分支容易出问题

长期分支落后主线

main

ABCD

feature

BEF

git rebase origin/main

同步主线后

main

ABCD

feature

DE'F'

短生命周期分支最大的优点，是漂移时间短、冲突面小。

长期分支恰恰相反。它一旦存在数周甚至数月，就很容易出现：

• 和主线差异越来越大
• 每次同步都变得更痛苦
• 冲突反复出现
• 历史里混入大量“为同步而同步”的噪声

所以长期分支最核心的目标，不是“永远不冲突”，而是把冲突拆小、把同步节奏固定下来。

什么情况下会保留长期分支

长期分支通常只在这些场景里才值得保留：

• 版本维护线
• 客户定制线
• 大型迁移项目
• 需要和主线并行很长时间的研发主题

如果一个分支本质上只是普通功能开发，却长期不合并，那通常是流程设计的问题，不是应该维护一个长期分支的问题。

推荐顺序

1. 设定固定同步节奏

不要等到“快合并了才想起同步”。更稳的做法是设一个固定节奏，比如：

• 每周同步一次主线
• 每个里程碑前同步一次
• 每次大批量改动前先同步一次

2. 尽量缩小每次整合范围

git fetch origin
git rebase origin/main

或者：

git fetch origin
git merge origin/main

关键不是一定选哪条命令，而是不要让积压跨度过大。

3. 定期处理历史债务

长期分支里最危险的不是冲突本身，而是“旧债越来越多却没人清理”。

这包括：

• 重复冲突点
• 已经无效的临时提交
• 为了救火留下的噪声历史

一个现实中的维护节奏

假设你们团队有一条持续 2 个月的迁移分支，比较稳的一套节奏可能是：

git switch migration/auth-refactor
git fetch origin
git rebase origin/main
git status
git log --oneline --decorate -8

每次同步后再马上做两件事：

1. 跑关键测试
2. 记录本次冲突集中在哪些文件

这样你会逐渐发现哪些区域是高频风险点。

merge 和 rebase 在这里怎么选

长期分支维护里，两种策略都可能成立，但关注点不同：

• merge：保留整合节点，适合希望明确看到同步历史的团队
• rebase：让长期分支更线性，但要求对重写历史的边界更谨慎

如果这条长期分支已经被多人共享，通常要先确认团队是否允许频繁 rebase。

关键检查点

建议每次同步前后都至少看：

git branch -vv
git diff --stat origin/main...
git log --oneline --decorate --graph -12

重点确认：

1. 这次同步之后，分支和主线的差距有没有缩小
2. 有没有引入新的大块冲突
3. 最近历史是否被同步噪声淹没

常见误区

误区 1：长期分支平时不管，合并前一次性解决

这往往会把同步成本放大成一次事故。

误区 2：一条长期分支里混入多个方向

分支越长，越需要主题边界清晰。

误区 3：只同步，不清理

如果每次同步都留下噪声提交，长期分支最终会越来越难维护。

特殊情况

• 如果长期分支服务的是旧版本维护，主线同步策略和产品线同步策略可能要分开看
• 如果该分支已经是多人共同开发主线，历史重写必须更谨慎
• 如果某些目录总是高冲突区，可以考虑进一步拆模块或减少并行改动

→长期分支维护期间要问的问题

1. 这个分支是否仍然代表一个连贯的主题？
2. 漂移是在缩小还是无声增长？
3. 哪些文件是重复的冲突热点？
4. 分支历史是在描述进展，还是大部分描述同步工作？

相关命令

• git fetch
• git rebase
• git merge
• git diff
• git log
• git branch

接下来建议继续学什么

这一页之后，通常值得继续看：

1. release branch workflow
2. hotfix and urgent fixes
3. squash vs rebase merge