第4章笔记：版本、配置与协作流

本章目标

把代码、依赖、环境和发布制品纳入可追踪的配置管理。 本章不是术语表，而是一条从问题到证据的工作链。先确认用户或团队要保护的结果，再把决定写进可版本化制品，最后由测试、指标、反例或演练证明它在边界与故障下仍成立。

七节联系

• Git提交是可审查的决策单元：好提交围绕一个可解释变化，包含测试并可安全回退；关键规则是提交应构建通过、意图单一、说明原因，并避免把密钥或生成大文件写入历史。
• 分支策略与主干开发：分支寿命越长，集成批量和不确定性越大；主干开发依赖小批量与自动门禁；关键规则是合并频率优先于分支仪式；任何长期分支都要有明确退出条件。
• 语义版本与变更日志：版本号向消费者传递兼容性承诺，变更日志解释迁移行动；关键规则是版本依据外部契约影响决定，不依据代码行数或开发时长决定。
• 依赖锁定与供应链证据：直接与传递依赖都可能引入漏洞、许可证和不可复现风险；关键规则是构建必须能从声明和锁定信息复现；高风险依赖要有所有者与替代计划。
• 配置、密钥与环境差异：配置是运行时决策，密钥是受控凭证；二者都不应硬编码进仓库；关键规则是构建制品跨环境不变；环境差异显式声明、校验并可审计。
• Feature Flag生命周期：开关可分离部署与发布，但会增加状态组合和遗留分支；关键规则是每个开关必须有类型、所有者、默认值、监控和删除日期。
• 合并冲突与共同所有权：冲突是并行决策相撞，应理解双方意图而不是机械保留两边文本；关键规则是解决冲突后必须重新构建和运行受影响测试，不能把‘能合并’当‘语义正确’。

学习时给七节画依赖箭头：前一节产出的对象、规则或制品如何成为后一节输入？若某节可以被随意挪走而完全不影响上下文，说明你仍在孤立背诵，需要用一个贯穿案例重新连接。

章内练习

1. 用“把折扣规则、测试和迁移说明放在同一原子提交，不混入无关格式化”重做正常、边界和故障三类验收，产出可由同伴复核的制品。
2. 用“团队用短分支和feature flag合入未开放功能，每日与主干集成”重做正常、边界和故障三类验收，产出可由同伴复核的制品。
3. 用“库从2.4.1修复漏洞升2.4.2，新增兼容API升2.5.0，删除旧接口升3.0.0”重做正常、边界和故障三类验收，产出可由同伴复核的制品。
4. 用“提交锁文件、生成SBOM、校验来源签名，并在升级机器人PR中运行回归与许可证门禁”重做正常、边界和故障三类验收，产出可由同伴复核的制品。

每次练习都保留背景、输入、决定、输出、验证、失败处置和负责人。只写结论不算完成；只贴截图也不算证据。完成后交换给同伴，只允许对方根据制品复现你的判断，无法复现处就是下一轮修改入口。

错误复盘

把错题标成目标误判、边界遗漏、责任空缺、契约不清、验证不足或恢复缺失。不要写“粗心”。一周后更换领域重做一道情境题；能在新名词下保持同一证据链，才说明方法已经迁移。阶段卷使用独立题池，不能靠记住随课题答案过关。