分支策略是交付周期统计失真的最大源头，选错或混用策略会导致lead_time和cycle_time成为“平均幻觉”；git分支模型决定可采集的时间点，tbd需require linear history以保pr时间，混合模型易漏feature分支工作；交付周期起止须绑定系统可验证锚点，起点为issue.created_at或pr.opened_at，终点为deploy.production.success；分支保护规则影响cycle_time准确性，未配对会掩盖协作耗时或导致数据异常；多环境发布需分层打标并补全preprod等不可见阻塞；真正关键在于每个时间戳都可反向追溯。
分支策略本身不直接产出交付周期数据，但它是交付周期统计失真的最大源头——选错策略或混用策略，lead_time 和 cycl_time 就会变成“平均幻觉”。
Git 分支模型决定你能度量什么
你用的是 git flow、trunk-based development (TBD) 还是混合模型，直接决定哪些时间点能被自动化采集、哪些环节必然靠人工补录。
-
git flow下，develop合并到release/*的时间点可捕获，但需求从 PR 创建到合入develop之间常有“等待合并窗口”空白期，这部分时长无法从 Git 日志还原 -
TBD模式下，main分支每次 push 都应对应一个可部署版本，lead_time可精确到 commit 级别，但前提是所有 PR 必须开启require linear history，否则 squash merge 会丢失原始 PR 创建时间 - 混合模型（比如部分团队用
feature/*+main直推）最危险：Git 日志里既存在 feature branch merge，又存在 direct commit，git log --oneline --since="2026-06-01"会漏掉 feature 分支上已开发但未合入的 work，导致吞吐率虚高
交付周期（Lead Time）必须绑定明确的起止事件
不能只依赖“需求创建时间”和“上线时间”两个字段做减法。中间必须有至少一个 Git 或 CI/CD 系统可验证的锚点，否则指标不可复现。
- 起点建议锁定为：
issue.created_at（Jira / Linear）或PR.opened_at（GitHub / GitLab），二者选其一并全团队对齐；混用会导致同一需求在不同看板中 Lead Time 差异超 48 小时 - 终点必须是生产环境真实生效时间，不是
CI pipeline success，也不是merge to main，而是：deploy.production.success（需对接 Argo CD / Spinnaker / 自研发布平台的 webhook 日志） - 如果使用蓝绿发布，终点应取新版本流量切至 100% 的时间戳，而非 deployment resource 创建时间——后者可能早于实际生效 5–15 分钟
分支保护规则直接影响 Cycl Time 统计准确性
cycl_time（从代码提交到上线）在多数工具里默认按 PR 生命周期计算，但若分支保护没配对，这个周期会被严重拉长或截断。
- 未启用
require pull request reviews before merging时，cycl_time会把“开发者自提自合”计入，数值趋近于 0，掩盖真实协作耗时 - 启用了
require status checks但 CI job 名称不固定（比如 Jenkins job 命名为build-<random_id></random_id>），会导致工具无法识别 check 完成时间，cycl_time中间段显示为空白或错误归为“blocked” - 允许绕过保护规则的 bypass 权限（如 GitHub 的 “bypass pull request requirements”）一旦被高频使用，
cycl_time数据将出现双峰分布：大部分集中在 2–4 小时，少量在 0.1 小时，这种分布无法用于流程优化判断
多环境发布场景下，交付周期要分层打标
一个需求走完 staging → preprod → production 三套环境，不能只记一个总时长。各阶段阻塞原因完全不同，混在一起统计等于放弃根因分析。
- 建议在 CI/CD 流水线中为每个环境部署步骤注入
env=staging、env=preprod等标签，并让度量平台按env字段自动拆解lead_time为三段 - 特别注意
preprod环境常被业务方卡住验收，这部分时长在 Git 日志里完全不可见，必须通过对接 Jira status change webhook 或测试平台验收事件来补全 - 如果某次发布跳过了
preprod（例如 hotfix 直发 production），度量系统应标记为skipped:preprod而非留空，否则 P85 统计会把这类例外当作正常流程拉低整体指标
真正难的不是算出一个数字，而是让每个时间戳都经得起反向追溯——当有人质疑“为什么这个需求 lead_time 是 72 小时”，你应该能立刻打开日志，指出哪一段卡在 Code Review，哪一段等了 QA 排期，哪一段因配置错误重试了三次。分支策略只是起点，后面每一步数据链路断掉，交付周期就只剩下一个好看但无用的平均值。
