如何在具有多个分支的团队环境中处理核心数据模型版本控制

Question

我正在寻找一个通用的过程来处理团队环境中的模型更改，特别是在使用像Git Flow这样的分支模型的地方。 我想使用轻量级迁移，但是我担心如果多个开发人员在其分支机构内进行版本控制，这将如何工作。

Answer 1

我更喜欢仅在需要对模型进行更改时才进行版本控制，而不是先发制人。

与团队合作时，我建议任何需要更改模型的人员与团队的其他成员一起检查是否可以对模型进行版本控制，主要是检查模型是否已被版本控制。 如果尚未进行版本控制，那么我会让开发人员发出拉动请求以仅针对模型版本凹凸进行开发。 合并后，需要为下一个版本进行模型更改的任何人都可以从开发中提取新版本的模型，并在该新版本上进行更改。 以我的经验，将来自不同分支机构的不同开发人员的更改合并到同一模型并不困难。

有了这些，我只考虑了轻量级迁移，这在大多数情况下可能是您所需要的。 对于手动迁移（这种情况可能很少见），我建议采用一种更临时的方法来满足项目的特定需求。

Answer 2

总的来说，我认为最好的方法是每个发行版对模型进行一次版本化 。

通常，

如果是早期开发（预发布）

无需版本控制（因此也无需迁移），因为这只会减慢开发速度。 开发人员和质量检查人员只需为每次型号更改重新安装应用程序。

应用准备发布后

在每个发行版的开始，即创建发行分支时，首席开发人员应在开发分支上创建新的数据模型版本。 这将使多个开发人员无需协调即可在功能分支上进行更改（即“谁将对模型进行版本化？以及我们如何将其引入我们的分支？”）。

不建议在release分支上更改数据模型

这可能会破坏从先前版本的迁移路径。