如何使用Flyway处理生产与主分支热修复后的版本冲突

问题核心 #

生产环境通过热修复版本V_635.1已应用主分支V_638的全部逻辑，但Flyway的schema_history表中无V_638的执行记录。现在发布主分支V_639时，Flyway会尝试执行未记录的V_638脚本，发现数据库对象已存在，触发冲突报错。

可行解决方案 #

方案1：用Flyway Repair标记V_638为已执行

• 先确认生产环境数据库状态：V_635.1的DDL/DML逻辑与主分支V_638完全一致，无数据或结构差异
• 在生产环境执行命令：

  flyway repair
  

  该命令会对比本地迁移脚本与schema_history表，自动将V_638标记为已成功执行（因为逻辑已存在）
• 执行完成后，运行flyway migrate即可正常执行V_639的迁移脚本
• 注意：执行前必须备份数据库，确保V_638与V_635.1的逻辑完全匹配，避免标记后出现数据不一致

方案2：调整主分支版本号（适合长期规范）

• 将主分支中V_638的脚本版本号修改为V_635.2，同时删除原V_638脚本
• 后续发布时，Flyway会识别V_635.2为未执行脚本，但需确保该脚本内容与V_635.1无重复逻辑
• 缺点：需要修改历史脚本，可能打乱团队版本序列规范，需团队统一确认后操作

方案3：用Flyway Baseline设定基准版本

• 确认生产环境数据库状态完全匹配主分支V_638的预期状态
• 执行命令：

  flyway baseline -baselineVersion=638
  

  该命令会将当前数据库状态标记为V_638的基准，Flyway后续会从V_639开始执行迁移
• 注意：Baseline会忽略V_638之前的所有迁移脚本记录，必须确保基准状态绝对准确

后续预防规范 #

• 统一热修复版本规则：生产分支热修复用V_X.Y格式，主分支合并热修复时直接沿用该版本号，而非新建V_X+1大版本
• 发布前预校验：每次生产发布前，对比生产环境schema_history与待发布分支的迁移脚本列表，提前发现版本冲突
• 分支同步机制：主分支合并生产热修复后，立即同步版本标识，避免两边版本号逻辑错位

内容的提问来源于stack exchange，提问作者Thathsara Radeeka