Git 与 CI：接口回归、冲突修复与交接｜课后复习
今天学会了什么
能用 fixture、参数化与合适替身验证本人商品导入和异步聚合模块；能修复合并后的语义错误，交接固定提交和可复现测试命令。
用图中两种冲突各对应一个你的项目例子，指出为什么删除冲突标记后还要运行合同和业务测试。
今天讲了什么（对照复习）
下面逐项对应课堂正文。先盖住右边那一栏，凭记忆回答；卡住了再翻回左边同名的小节。光说得出名字不算会，还要能讲清它会做什么、什么时候会失效。
| 课堂对应章节 | 必须能解释的机制与边界 |
|---|---|
| 文本冲突解决，不等于语义冲突解决 | Git 分支记录不同提交路径；合并无文本冲突不代表业务兼容。合并后查冲突标记、字段与异常合同、目标与全量回归，不能用 Already up to date 证明业务正确。 |
| README 是可执行的交付说明；同伴反馈怎样回到仓库 | 说明获取固定版本、环境、依赖、配置、样本、API 启动与验证、排错和限制。反馈写提交、环境、命令、原始错误、预期与实际；修复形成新提交并由同伴重新执行。 |
| 本地通过不等于远端提交通过；先建立本地绿色基线；CI 结果必须关联 commit SHA | 本地工作区可能有未提交文件和隐式依赖；CI 从指定提交重建。记录 SHA、运行命令、测试环境和工作区状态，旧提交绿灯不能替新代码背书。 |
| CI 是什么 | 持续集成获取版本、准备环境、执行检查并保存结果；持续交付产生可部署制品，持续部署还会送入指定环境。当前 CI 绿灯不等于完成生产部署。 |
| 测试分层；Fixture 不等于真实环境 | Service 单测检查规则，API 合同测试检查输入输出，MySQL 集成检查关系事务，容器冒烟检查打包运行。fixture 是准备与清理机制，可以承载真实库或替身，证据取决于实际执行环境。 |
| 一个最小 CI 工作流要回答什么 | 识别 on、jobs、runs-on、steps、uses/run、working-directory 与依赖关系；写清 Python、锁定依赖、数据库、配置、schema/seed、测试和日志。不要只跑 import，也不为绿灯删约束。 |
| 先故意制造一次 CI 失败 | 选择可控缺失依赖／配置／初始化故障，保存失败提交和首个错误；修复后关联新提交及结果，说明具体原因而非只贴绿灯。 |
出了问题：怎么发现、怎么修、怎么验证
只在你自己那份课程副本或专用实验数据上复验，把改之前和改之后的真实结果都留下来。
| 风险／现象 | 提前预防 | 怎样发现 | 怎样处理 | 怎样复验 |
|---|---|---|---|---|
| 合并无冲突但错误语义变了 | 先列跨文件合同和目标用例 | 比较异常、状态码与页面依赖 | 按统一合同合并，补回归用例 | 合并版本的目标及全量测试通过 |
| 本地绿与 CI SHA 不一致 | 交付前核对提交和工作区 | 对照本地 HEAD 与 CI 运行关联提交 | 提交必要修改后重新验证对应版本 | 交付 SHA、CI SHA 和同伴版本一致 |
| CI 隐藏依赖或初始化缺失 | 明确依赖、配置及 schema/seed 步骤 | 读取首个失败步骤和原始日志 | 修缺失步骤，保留数据库隔离 | 新运行从干净环境通过相关检查 |
| 用替身或冒烟结果代签真实环境 | 每种测试写明资源和范围 | 检查跳过项、服务连接和测试类别 | 补对应真实验证或标待验证 | 规则、合同、MySQL、容器证据分开 |
| README 依赖作者口头补充 | 让同伴只读说明执行 | 记录第一次卡住的命令和缺失前置 | 将真实步骤写回 README | 同伴按新提交重新启动并验证 |
本日新增 Python 知识怎样进入商城
pytest fixture、tmp_path、参数化、raises、monkeypatch/AsyncMock 边界；复用 Git 合并、CI SHA、接口回归。它们共同支持“用本人代码证明回归与交接可靠”。我应能打开 test_ops_student.py 指出每个机制的位置，并重跑 坏单价参数化；生成器真实消费；缺配置隔离；聚合器合同替身；故意放宽规则使测试变红；修复语义冲突。
| 风险 | 提前预防 | 怎样发现 | 怎样处理 | 怎样复验 |
|---|---|---|---|---|
| 测试看似通过却没检查规则 | 先列输入与应失败行为 | 故意破坏规则仍不红 | 调用真实被测函数并补业务断言 | 故意错误红、恢复后绿 |
| 共享样本或替身扩大结论 | tmp_path/fixture 隔离，外部层单列 | 运行顺序影响结果，缺真实请求证据 | 恢复测试状态、缩小 mock 范围 | 独立重跑结果一致，真实服务仍单独验 |
闭卷自测
先自己答一遍，再去运行或翻回课堂核对；不确定的地方标出来，别用 AI 的答案顶掉你自己的第一次判断。
-
文本冲突与语义冲突各举一例；自动合并后还需检查什么？
-
解释本地 HEAD、工作区未提交变化和 CI SHA 的关系。哪个版本才是交付对象？
-
工作流中的 on、jobs、steps、uses 和 run 分别做什么？数据库初始化漏了会在哪一层暴露？
-
Service 单测、API 合同、MySQL 集成与容器冒烟分别保护什么？fixture 为什么不等于 Fake？
-
CI 通过、制品生成和生产部署完成有何差别？给同伴什么证据才能让他复验修复？
-
生成器测试为什么必须真正消费？mock 被测函数为何可能产生假绿？怎样用一次故障注入证明断言会拒绝错误实现？
再看一眼真实业务
用预习记录的真实变更说明练习“变了什么—影响谁—怎样验证”。外部发行页没有 CI 结果就保留未知，在自己仓库建立可核对的版本与测试关联。
今天留下什么，下节课怎么接着用
同时保留针对本人 commerce_ops 的回归测试和一次故障注入结果，W03 在这份基线上增加并发运营工具。
保留可复现 API、依赖和配置说明、合并修复、失败／修复 SHA、CI 结果及同伴冷启动记录。W03-D01 在这一稳定版本上测试并发正确性与索引，不重新安装整套环境。
远端未运行、目标数据库未验证或同伴未执行的项目如实标为待验证；不将 CI 绿灯写成生产部署或全班可运行。
补充交接：W03 继续本人服务和运营模块，增加线程/进程、缓存、权限与网页交互。本人 commerce_ops 每天增量合并，不用后一天骨架覆盖前一天实现。