我一直在尝试使用Liquibase或DBDeploy。我更喜欢 Liquibase，因为它的非 SQL 接口（即我可以只使用 JSON 或 Yaml 变更集）。但是，这两个软件都有一个问题。
includeAll一个文件夹，其中包含带有小变更集的小文件。好吧，这个问题是如此微不足道，我觉得问它很愚蠢，但它就在这里。考虑这种情况：
这不会发生在任何人身上吗？如果是这样，在PHP领域解决它的方法是什么？
谢谢。
（我只知道 liquibase - 所以我的回答只对 liquibase 有效）
正如includeAll文档所述，文件将按字母顺序运行。所以我希望您的编号应该足以使文件按正确的顺序排列。但是，无论如何，您都必须在您和 Bob 之间同步这些数字，以找出必须首先运行的内容。
虽然我们不使用includeAll。我们手动将文件包含到主更改日志中。因此，任何想要更改数据库的人都必须注意将其包含在主更改日志中。如果有两个更改，最后出现的开发人员必须确保在主更改日志中的正确位置包含/合并他的更改。
已编辑 - 解释我们使用的包含机制
在开发过程中，我们只是不及格整个数据库，并让 liquibase 每当我们更改任何内容（在我们的开发数据库上）时从头开始创建数据库。我们总是将变更集文件签入到我们的代码存储库中。因此，我们可以跟踪开发中所做的所有事情，因为我们可以检查变更集的每个版本并让 liquibase 使用它创建数据库。
只有当我们正在开发的版本（或冲刺）完成时。然后我们真的让变更集运行，并让它们改变生产数据库。
然后这个循环一次又一次地重复。
这样，liquibase 只会跟踪最终的数据库更改，而不是在开发过程中可能发生的所有试验。
在开发过程中，您最终可能会多次更改表，因为您尝试了不同的东西。您添加了一列，然后意识到整个事情将无法正常工作，因此您再次删除该列并添加另一列。为什么要在 中进行所有这些更改databasechangelog？然后它会充满不必要的东西——就像你害怕的那样。
希望这可以解决问题。但最终你可能会有完全不同的开发方法。因此，请随意按照您需要的方式使用 liquibase。
在开发过程中没有理由用所有的想法来填充 databasechangelog 表。只有当我们完成开发并发布版本时
我使用了几个不同的迁移框架——Liquibase、Rails 以及来自 C# 世界的名为 Tarantino 的东西。每个人都使用类似的策略，将更改记录在单独的文件中。每个人都在一个小团队中（<= 5 个开发人员）。
Rails 是关于如何命名文件的最教条的，也是我因分支而遇到最多冲突的地方。大多数冲突是基于名称的，而不是数据库中的逻辑冲突。
在使用 Liquibase 的项目中，我们使用了主/包含模式，开发人员在分支上进行工作。因为文件名有一个 3 位数的序列号加上一个简短的描述（即 009-add-customer0index.xml），所以我们没有名称冲突。我们主要通过彼此交谈来避免数据库级别的冲突——每日站会等。
我们在使用 Tarantino 时也有类似的经历，尽管它只是使用一个充满文件的目录进行迁移。与 Liquibase 一样，我们采用了一种命名约定，使事情井井有条。即使两个变更集具有相同的编号，它们也会有不同的名称，而且在 99.9% 的情况下，这两个变更集的顺序并不相互依赖。
仅对于一个数据点，使用 Tarantino 的项目通过大约 400 个变更集趋于平稳。