警告：问题较长。
[问题]
如果按照下面所描述的方式，每个数据库都有一个分支，并进行版本控制，那么在尝试合并到更少的分支时，如何处理数据迁移问题？
当您尝试合并到更少的分支时，如何管理数据迁移问题？
这只是作为数据迁移的一部分而产生的成本吗？
实质上，在迁移时将不得不创建转换脚本。
是否有更好的方法？
我们可以同时解决这两个问题吗？
什么是最佳实践？
[背景]
在我的工作场所，我们有一个产品，有3个分支。主线拥有“最新和最伟大”的变化，这不一定准备好发布。
- 版本B（名称已更改以保护罪犯）
- 版本A（名称已更改以保护罪犯）
- 主线
由于这些分支，实际上有3个版本的数据库。 代码版本控制相当容易，但数据库版本控制似乎很困难。
阅读您是否对数据库项目使用源代码控制？后，似乎最好的方法是为每个对象/表导出所有创建脚本。 注意：根据文章，如何管理它，是一个大脚本、多个脚本还是混合体，取决于您的喜好。
我同意这一点，并询问为什么不这样做。
目前，数据库管理员拒绝将脚本分支到各个分支中。 除了懒惰作为借口外，原因是为了节省数据迁移时间。 实际上，强制在所有版本中维护数据库更改。
所有脚本都经过版本控制，并仅在主线上维护。 版本A和版本B有自己的特殊文件，指定要在其各自的分支上运行哪些更改脚本。当存在更改脚本时，例如应用于版本A但版本B仅需要部分更改时，开发人员必须通知数据库管理员更新文件，该文件指示要为每个分支应用哪些补丁。对于执行太多手动干预的更改脚本，需要手动应用更改脚本的一部分。
要更新版本A上的数据库，需要使用版本A的补丁应用文件提取所有补丁。
[场景]
- 存在上述3个版本。
- 对版本A进行数据库更改。
- 合并代码从版本B到版本A，以便删除版本B。
- 数据库也需要进行相同的操作。
希望这有意义。