使用要素分支时如何使用 Flyway

我所见过的克服分支之间的版本控制问题以启用outOfOrder并使用时间戳作为版本号的最佳方法

默认情况下，大多数迁移框架选择在各个迁移前面加上整数前缀，如下面的示例所示。当框架遇到尚未应用于当前数据库的迁移时，它从数据库中不存在前缀的第一个迁移开始，并开始按升序应用它们。

• 1.0.0.1__add_customers_table.sql
• 1.0.0.2__add_email_address_column_to_customers_table.sql
• 1.0.0.3__add_orders_table_with_reference_to_customer_table.sql

当每个人都在同一代码分支上时，这很有效。但是，一旦团队成员开始在自己的分支上工作，前缀冲突的可能性就会大大增加。

但是，如果您选择使用时间戳而不是整数作为迁移的前缀，则冲突的可能性几乎会消失，即使跨分支也是如此。例如，使用诸如yyyyMMddHHmmssSSS之类的模式，上面的迁移现在看起来像...

• 1.0.0.20130704144750766__add_customers_table.sql
• 1.0.0.20130706132142244__add_email_address_column_to_customers_table.sql
• 1.0.0.20130706151409978__add_orders_table_with_reference_to_customer_table.sql

上面的时间戳模式精确到毫秒。虽然高度精确的时间戳可能会导致难以阅读的前缀，但前缀越精确，发生冲突的可能性就越小。

为了获得最佳效果，您需要自动创建此时间戳，以便团队的所有成员都使用一致的格式

此外，请注意，Flyway 还将时间戳前缀视为整数。这意味着，如果您最初开始使用整数使用Flyway，那么您仍然可以随时切换到时间戳。由于时间戳只是非常大的整数，因此第一个时间戳前缀迁移将仅在最后一个整数前缀迁移之后应用。

从这里取并稍作修改：http://www.jeremyjarrell.com/using-flyway-db-with-distributed-version-control/

您不能拥有与您将获得的版本号相同的迁移记录：

发现多个版本为“x.y.z”的迁移（违规者：SQL ...）

以下是我建议的解决方法：多个开发人员正在使用相同的版本，例如，但功能不同。我猜你正在使用一些问题跟踪器，为每个问题添加ID，例如.当开发人员处理该问题时，迁移脚本称为 。这样（假设每个功能/分支都有自己的问题），就不会有冲突。1.0FOO-16V1.0.16__my_greatest_feature.sql

此外，我假设数据库迁移脚本是独立且不重叠的，但是如果不是这种情况，则在将所有内容合并到稳定版本时会遇到问题。

因此，在稳定版本中，您有几个带有间隙的迁移脚本，例如：，，（如果，和已选择） - Flyway不会在乎。所有未进入稳定版本的功能（例如）都应重命名为针对下一个主要版本（例如 ）。V1.0.16V1.0.27V1.0.101FOO-16FOO-27FOO-1011.0V1.0.35V1.1.35