目前，我们公司通过手动创建、分发和运行必要的 SQL 脚本来处理所有数据库架构更改。显然，这会导致问题，因为各种机器会零星且稀疏地更新。
我正在研究更现代的方法来处理这个问题，而 Flyway 是目前的主要候选者（尽管如果可以为此提出令人信服的论点，我们仍然愿意使用 Liquibase）。
正常的流程很简单，并且像宣传的那样简单，但我们不知道如何正确解决冲突的迁移脚本。例如，不同个人分支（A 和 B）的 2 个开发人员在不同的迁移（MigrationA 和 MigrationB）中将同一列添加到表中。分支 B 上的开发人员意识到，在他已经在他的数据库上运行 MigrationB 之后，它就没有必要了。不幸的是，此时损坏已完成，并且已将条目写入数据库 B 中的 schema_version 表。由于 Flyway 不支持回滚，在这种情况下，适当的响应是什么？
从历史上看，我们已经尽可能避免删除/重建我们的数据库，但是一旦您使用 Flyway，这种心态就已经过时了吗？我们是否应该彻底地创建 DeveloperData 脚本，以便我们可以在出现这些问题之一时删除我们的数据库？在我开始告诉同事我们需要立即开始丢弃我们的数据库之前，我想确保我以正确的方式处理这个问题。
感谢您提供有关人们如何成功切换到 Flyway 的任何输入特定答案或更一般的解释/示例。