核心问题

如何从 commit、PR、issue 和事故复盘里理解过去的技术决策？

真实场景

你看到一个很奇怪的字段 legacy_status。没人知道它为什么存在。代码注释也很少。

但 Git 历史里有一条 PR：当年为了兼容旧订单系统，临时加了这个字段，后来迁移没有完成。

答案不在当前代码里，而在历史里。

常见误区

坏判断是：

当前代码就是全部真相。

代码告诉你系统现在是什么，历史告诉你它为什么变成这样。

工程视角

Git 历史能提供：

  • 变更时间。
  • 变更作者。
  • 关联需求。
  • 当时讨论。
  • 被放弃的选项。
  • 历史事故背景。

这些信息能帮助团队判断一段逻辑是否还能改。

PM 可以怎么做

PM 可以建立“历史追踪”习惯：

  • 让重要 PR 关联需求或 issue。
  • 要求关键变更写清楚原因。
  • 对旧系统疑点查 commit 历史。
  • 把事故结论回连到相关代码。

Atlas Action

遇到不敢改的旧逻辑时，和工程师一起查三样东西：

git blame
相关 PR
相关 issue / 事故复盘

小结

Git 历史是系统的记忆。

PM 学会使用这份记忆，就能少做很多“重新踩坑”的决策。