分支停留时长是暴露协作节奏断裂、流程卡点与质量门禁失效的关键信号，需以CI首次触发或Jira关联Sprint时间为起点计算，而非最早提交时间；feature/sprint-*超10天、hotfix超4小时、反复rebase未提MR等三类须告警。
分支停留时长不是“代码没合进去”的简单计数，而是暴露协作节奏断裂、流程卡点、质量门禁失效的关键信号。超过 7 天未合入的 feature/* 分支，80% 的概率已脱离当前 Sprint 节奏，继续放任只会放大集成风险。
Git 分支停留时长怎么算才反映真实瓶颈
直接用 git log --oneline feature/sprint-25-login 看最早提交时间是错的——那只是开发起始点，不是“进入交付流”的起点。真正该追踪的是分支首次关联到项目管理工具（如 Jira、Teambition）对应 Sprint 的时间，或 CI 流水线首次触发的时间。
实操建议：
- 在 CI 配置中为每个
feature/*分支作业注入环境变量CURRENT_SPRINT_ID，并在流水线日志首行打标，作为“进入交付流”锚点 - 用 GitLab API 拉取
merge_requests列表，过滤source_branch匹配feature/.*且state == "opened"，再结合created_at字段计算天数 - 排除
exp/*和tmp/*类实验性分支，它们不参与交付节奏评估
哪些分支停留时长必须告警
不是所有长时分支都危险，但以下三类需立即介入：
-
feature/sprint-25-*类分支存活 > 10 天：说明 Sprint 计划失准或任务拆解过大，已违背 Scrum “时间盒”原则 -
hotfix/*分支从创建到合入 > 4 小时：反映线上问题响应链路存在审批、测试或部署阻塞 - 同一
feature/*分支被反复rebase超过 3 次且未发起 MR：大概率是开发者在本地修冲突、补逻辑，却未暴露协作问题
注意：main 分支上无新 commit 超过 48 小时，也应触发告警——这不是分支停留问题，而是交付流停滞的更严重信号。
Gitee 企业版效能看板里该盯哪几个字段
Gitee 企业版的「工作项各状态停留时长分布」模块默认只展示需求/缺陷维度，要真正看清分支瓶颈，必须手动配置数据源映射：
- 把 CI 流水线中
job.name == "test"的started_at→ 映射为「测试就绪时间」 - 把 MR 的
merged_at或closed_at（若被拒绝）→ 映射为「交付完成时间」 - 禁用「按创建时间聚合」，改用「按分支名前缀分组」，例如提取
feature/sprint-(\d+)-中的数字作为 Sprint ID
这样导出的看板才能对比出：Sprint-25 的平均分支停留 6.2 天，Sprint-24 是 4.1 天——上升不是因为开发慢了，而是 Sprint-25 的 MR 平均等待人工评审超 38 小时。
分支停留时长本身不产生价值，它只是把藏在协作缝隙里的延迟具象化。最常被忽略的是：MR 提交后到第一次 reviewer 点击「Approve」之间的时间差，这个值在多数团队里比构建和测试耗时还长，但它不会出现在任何 Git 命令输出里，只能靠 CI 日志与评审系统联动捕获。
