使用flyway将git配置为对具有不同名称模式的文件执行diff-on-commit

我们使用git来管理代码存储库

我们的存储库之一是使用

flywaydb

的数据库迁移存储库

数据库具有随时间变化的状态和对象依赖性，因此使用flyway的最佳实践是使用时间戳或数字，然后使用脚本名称，使文件前缀递增。通过这种方式，文件按字母顺序（按时间顺序）列出，并由

flyway

按顺序执行，它跟踪上一个脚本的运行状态，并可以运行丢失的脚本

问题是，当文件随时间顺序命名时，它们会替换相同的数据库对象（如数据库视图），我们如何配置git或flyway，以便在提交时，git足够聪明，可以根据一个模式而不是该文件的早期版本，对具有不同名称的文件进行文件差异处理

例如，我创建了一个视图，几天后有人更新了该视图。。。它需要两个文件，例如：

V20181121131512__create_myview.sql
V20181126235217__replace_myview.sql

在每个视图中，我们创建或替换一个视图，然后更新它。我想知道是否有任何方法可以将git配置为在提交时根据文件命名模式进行区分。例如，后缀，将用于相同的数据库对象名称

我不想在有很多拉请求需要审查的时候一直进行手动差异，我想快速查看不同开发人员之间的更改，以加快我的审查时间。但随着时间的推移，数据库状态的顺序命名会将数据库对象的先前代码强制放入不同的文件中，因此对同一数据库对象（如

SQL

视图）的每次提交“似乎”都是一个全新的文件，并且没有可与之比较的历史记录

---

你对如何处理这个问题有什么想法吗？git是否可以配置为在提交时根据文件命名后缀模式进行区分？或者，是否有另一种替代方法来构造flyway文件的repo和文件命名，以便可以解决数据库随时间变化的状态？

您可以通过切换到所有不直接保存数据的长寿命对象来完全避免此问题

---

它们允许您将视图的历史记录保存在Git中的同一个文件中。Flyway将在其校验和更改时自动重新应用它。

您的文件中保存的是文本或二进制数据吗？您使用的是什么数据库？感谢Axel，我没有考虑对其中一些文件进行可重复迁移Flyway版本控制。。。但是对于像视图这样依赖于正在创建的表的事物，如果需要在视图之前的特定时间点创建表，它如何解决这个问题？用一个迁移脚本跟踪事后的视图是很好的，但我不确定这是如何绕过所需的先验状态的，即使是事后，一个文件就足以管理对象了？@Mark:我不使用Flyway，但对于Liquibase和Postgres，我们在开始时有一个脚本，它总是被执行，只是删除数据库中的所有视图。然后，我们可以更改任何表，而不必处理视图和表之间的依赖关系。在所有“表”迁移之后，我们只需重新运行所有视图定义。@标记可重复迁移总是在版本化迁移之后执行（您应该使用它来创建表）