必须设定明确分水岭时间点，如2026-07-25 18:00停止维护旧分支feat/user-profile-v2等，并同步更新README、清理本地stale分支、禁用旧分支CI监听，避免CI误触发、权限绕过和开发者心智负担。
重构期间怎么避免所有人卡在旧分支上？
直接删掉旧分支会中断协作，但放任不管又导致混乱。过渡期必须有明确的“分水岭时间点”，而不是模糊说“下周清理”。
- 用
git branch -r | grep -v '\->' | sed 's/origin\///' | grep -v 'main'列出所有待过渡的远程分支名 - 在团队群明确公告：旧分支
feat/user-profile-v2、bugfix/cache-leak等将在 2026-07-25 18:00 停止维护，此后所有新提交必须基于main - 同步更新 README.md，在顶部加一行：
⚠️ 注意：自 2026-07-25 起，所有开发请基于 main 分支新建 feat/xxx
旧分支代码怎么安全迁移到新模型？
不是简单 cherry-pick 或 merge，而是按语义拆解——哪些是已完成逻辑，哪些是半成品，哪些已废弃。
MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub
下载
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
- 已完成但尚未合入的 feature 分支：用
git rebase -i main整理提交，确保每条 commit 语义清晰，再以 PR 方式合并到main - 写了一半但暂时不推进的分支：用
git worktree add ../tmp-worktree feat/user-profile-v2单独保留，不 push，也不关联 CI - 明显过时或重复的分支（如
tmp-refactor-2025）：确认无 reflog 引用后，直接git push origin --delete tmp-refactor-2025
为什么不能一边用旧分支一边推新模型？
表面看兼容，实则埋下三类隐患：CI 误触发、权限策略错配、开发者心智负担加重。
- CI 配置若仍监听
feature/*，就会为已弃用分支跑构建，浪费资源且掩盖真实问题 - 分支保护规则（如 require 2 reviewers）若只设在
main，旧分支 push 直接生效，绕过质量门禁 - 新人看到 20+ 个
feature/分支，第一反应是“该从哪个拉？”，而不是“我该建哪个”
过渡期最易被忽略的细节
不是命令怎么敲，而是本地环境是否同步。很多人改完远程，却忘了自己本地还留着几十个 stale tracking branch。
- 执行
git fetch --prune清理本地对已删远程分支的引用 - 运行
git branch -vv | grep '\[gone\]'找出已失效的本地分支，逐个git branch -d branch-name - 检查 IDE 的 Git 插件缓存——IntelliJ 默认不自动刷新 remote branch 列表，需手动右键 “Reload project from Git”
