如何让Flyway的baseline与outOfOrder特性协同工作？
我来给你拆解下这俩特性怎么配合用，尤其是你提到的分支开发里cherry-pick补丁的场景——这种情况在实际项目里太常见了，稍不注意就会踩坑。
首先得先明确两个特性的核心作用，搞懂了才好配合：
- Baseline：给已有运行状态的数据库设置一个「基准版本」，让Flyway从这个版本开始追踪后续迁移，不用从头执行所有历史脚本，相当于给数据库打个“快照标记”。
- OutOfOrder：打破Flyway默认的严格版本号顺序执行规则，允许执行版本号早于当前已执行最高版本的迁移脚本——不会把这些“滞后”的脚本标记为
Ignored，而是检测到未执行就直接跑，完美适配分支补丁回溯的场景。
咱们结合你说的例子一步步看怎么操作：
假设你的数据库已经有迁移版本1.0、1.1、1.2，现在从分支cherry-pick了一个补丁脚本（针对旧逻辑修复），版本号设为2.2；后续常规开发又发布了2.0、2.1版本（版本号反而比2.2低）。要让Baseline和OutOfOrder协同工作，步骤如下：
先给已有数据库设置正确的Baseline（如果还没弄）
如果你的数据库是已经在生产/测试环境运行的（不是全新初始化），首先得用flyway baseline命令把当前数据库状态和已有的1.2版本绑定：flyway baseline -baselineVersion=1.2 -baselineDescription="基准版本：当前生产环境已完成1.0-1.2迁移"这一步会在Flyway的元数据表（默认是
flyway_schema_history）里插入一条基准记录，告诉Flyway：“1.2及之前的版本都已经生效了，后续只需要追踪这个版本之后的迁移”。开启OutOfOrder模式
你可以在Flyway的配置文件（比如flyway.conf）里永久开启：flyway.outOfOrder=true或者在每次执行迁移命令时临时加上参数：
flyway migrate -outOfOrder开启后，Flyway就不会再死卡版本号顺序了，而是逐个检查脚本是否已经执行过——没执行的，不管版本号比当前最高版本高还是低，都会正常运行。
执行cherry-pick的2.2补丁
把你的补丁脚本（比如V2.2__fix_old_bug.sql）放到Flyway的迁移脚本目录里，执行flyway migrate。此时Flyway发现2.2比当前最高的1.2版本高，会正常执行这个补丁，同时更新元数据表，把2.2标记为已执行，当前最高版本变成2.2。后续处理2.0、2.1版本
当常规开发的2.0、2.1版本脚本（V2.0__add_new_feature.sql、V2.1__optimize_performance.sql）过来时，因为OutOfOrder已经开启，Flyway会检查到这两个脚本还没执行——哪怕它们的版本号比2.2低，也不会被忽略，而是依次执行。执行完成后，flyway_schema_history里会记录2.0、2.1、2.2都已执行。
最后给你提几个注意点，避免踩坑：
- Baseline版本必须和数据库实际状态匹配：如果基准版本设错了，比如数据库已经是1.2，但你设成1.0，Flyway会尝试执行1.1、1.2的脚本，直接导致重复执行报错。
- 不要随便开启OutOfOrder：只有在分支cherry-pick、回溯补丁这种特殊场景下用，常规开发还是尽量按版本号顺序来，不然脚本版本混乱了后期很难维护。
- 元数据表要保护好：
flyway_schema_history是Flyway的核心追踪依据，别随便手动修改里面的记录，不然会导致迁移状态混乱。
内容的提问来源于stack exchange，提问作者Alluir
