描述起来有点复杂，但我会尽力而为。基本上我们使用的是 Git 工作流程，这意味着我们有以下分支:
- production，即实时分支。一切都在实时网络环境中运行。
- 集成，其中集成了所有新功能。这个分支每周都会 merge 到生产中。
- 一个或多个功能分支，开发人员或开发团队在其中开发新功能。完成后，开发人员将他们的功能分支 merge 到集成中。
所以，这里没有什么真正复杂的。但是，由于我们的应用程序是针对 MySQL 数据库运行的 Web 应用程序，因此新功能通常需要更改数据库方案。为了自动执行此操作，我们使用了 dbdeploy，它允许我们在给定数字的情况下创建更改脚本。例如。 00001.sql、00002.sql 等。 merge 到集成分支后，dbdeploy 将检查哪些更改脚本的编号高于该特定数据库上最新执行的脚本，并将执行这些脚本。
现在假设如下。 - 集成更改脚本直到 00200.sql。所有这些都在集成数据库上执行。 - 开发人员 John 有一个功能分支 featureX，它是在集成仍然以 00199.sql 作为最高更改脚本时创建的。
John 创建 00200.sql 是因为需要更改一些数据库架构。
现在，John 将在某个时候将他的修改 merge 回集成分支。 John 将遇到 merge 冲突，并会看到他的 00200.sql 已存在于集成中。这意味着他需要打开冲突文件，提取他的内容，将该文件重置回“我的”(集成时的原始状态)并将他自己的内容放入一个新文件中。
现在，由于我们与十位开发人员合作，我们每天都会遇到这种情况。虽然我们确实理解这背后的原因，但有时它非常麻烦。 John 重命名他的脚本，对集成进行 merge 提交，将更改推送到上游，结果发现其他人已经创建了 00201.sql，需要 John 再次执行这些过程。
肯定有更多的团队使用 Git 工作流并使用数据库更改管理工具来自动执行数据库架构更改吗？
所以，简而言之，我的问题是:
- 在不同的功能分支上工作时，如何自动更改数据库架构，这些分支在同一数据库的不同实例上运行？
- 如何始终防止 merge 冲突，同时仍然可以选择在执行的更改脚本中采用固定顺序？例如。 00199.sql 必须在 00200.sql 之前执行，因为 00200.sql 可能依赖于 00199.sql 中完成的某些操作。
当然欢迎任何其他提示。
最佳答案
Rails 曾经这样做过，完全符合您描述的问题。他们更改为以下方案:文件(rails 称它们为迁移)标有文件创建时间的 utc 时间戳，例如
20140723069701_add_foo_to_bar
(名称的第二部分不影响排序)。
Rails 会记录所有已运行的迁移的时间戳。当您要求它运行挂起的迁移时，它会选择时间戳不在已运行迁移列表中的所有迁移文件，并按数字顺序运行它们。
除非两个人在完全相同的时间点创建一个，否则您将不再遇到 merge 冲突。
文件仍然按照您编写它们的顺序执行，但可能与其他人的工作交织在一起。从理论上讲，您仍然会遇到问题——例如，开发人员 a 决定重命名我已经决定添加一列的表。这比 2 个开发人员都对数据库进行任何更改要少得多，即使不考虑架构更改，您也会遇到问题大概我刚刚编写了查询不再存在的表的代码 - 在某些时候从事相关工作的开发人员会有互相交谈!
关于database - 如何处理来自不同 Git 功能分支的多个 db alter 脚本？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24658443/