应优先用 merge 控制历史深度，因 rebase 仅适用于未推送的私有分支，公共分支必须用 merge --no-ff 保证可追溯性；混用会导致 SHA-1 不一致与追踪混乱。
git log --graph 输出太长，怎么快速定位关键节点
分支历史树变深，不是因为提交多，而是因为合并策略和分支生命周期没约束。默认 git merge 会生成 merge commit，每次 feature 合并到 main 或 develop 都加一层“桥”，树形结构迅速发散。想一眼看清主干演进，得主动控制拓扑形态。
- 用
git log --graph --oneline --all --simplify-by-decoration过滤掉仅被分支引用、无标签/HEAD 指向的提交，大幅压缩视图 - 避免无意义的 fast-forward 合并：对已 rebase 整洁的 feature 分支，强制用
git merge --ff-only，失败就说明有分叉，需人工干预 - 定期清理已合并的本地分支：
git branch --merged main | grep -v 'main\|develop' | xargs git branch -d
merge 和 rebase 哪种更适合控制历史深度
答案取决于分支是否共享。rebase 不是“美化历史”的工具，而是为**未推送的本地分支**重写线性路径；merge 才是表达协作真实时序的机制。混用两者会导致同一逻辑变更在不同分支上出现不同 SHA-1，引发后续追踪混乱。
- 私有分支（仅你本地）：用
git rebase -i合并小提交、修正 commit message，再推送 - 公共分支（多人基于其开发）：禁止 rebase，只用
git merge --no-ff，确保每个功能合入都有明确 merge commit 可追溯 - CI/CD 流水线中检测到 rebase 后的 force-push，应直接拒绝 —— 这是防止历史被篡改的关键防线
长期存活分支导致历史膨胀，该怎么切分
一个分支存活超过两周，基本就在制造“历史黑洞”。不是所有分支都该长期存在。dev、main 这类集成分支必须存在，但 feature/*、bugfix/* 必须有明确的生命周期终点。
GitHub Actions Runtime Regression Audit
下载
对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。
- 设定分支 TTL（Time-To-Live）：CI 脚本检查
git branch --format='%(committerdate:iso8601) %(refname:short)' --sort=-committerdate，自动归档或删除超期分支 - 用命名规范强制收敛：比如
feature/login-v2-202607中的日期表示预期上线窗口，过期即失效 - 禁止在长期分支上直接提交：给
main和develop设置 protected branch 规则，只允许 PR 合并，且 PR 必须通过 CI + 至少 1 人 approve
Git reflog 能救回误删分支，但别依赖它
git reflog 确实能找回刚删掉的分支指针，但它只存本地操作记录，有效期默认 90 天（gc.reflogExpire），且不跨机器同步。把它当“后悔药”用一次两次可以，当成分支管理兜底方案就是自欺欺人。
- 删分支前执行
git branch -v -r | grep your-branch-name，确认远程也已同步合并 - 关键分支（如 release/v2.4）打 tag 后再删，tag 永久锚定，比分支指针可靠得多
- 团队内约定：所有正式发布必须有
vX.Y.Ztag，所有 hotfix 必须基于对应 tag 拉分支，而非某次 merge commit
真正难控的不是分支数量，而是分支之间缺乏明确的依赖边界和销毁契约。历史树复杂，往往是因为没人敢删分支、没人敢拒绝 merge、没人定义“这个分支到底什么时候算完”。
