饮冰三年-人工智能-Django淘宝拾遗-83-migrations文件

一、migrations文件维护

我们使用Django框架时通过ORM维护数据模型，会碰到一个问题生成的migrations文件越来愈多，这些文件如何更好的进行代码维护。

1：官方说明

官方建议提交，并且在服务器端应该直接执行 migrate，不需要再次生成migritions。

You should think of migrations as a version control system for your database schema. makemigrations is responsible for packaging up your model changes into individual migration files - analogous to commits - and migrate is responsible for applying those to your database.
The migration files for each app live in a migrations directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues’ machines, your staging machines, and eventually your production machines.

你可以想象 migrations 相当一个你的数据库的一个版本控制系统。makemigrations 命令负责保存你的模型变化到一个迁移文件 - 和 commits 很类似 - 同时 migrate负责将改变提交到数据库。
每个 app 的迁移文件会保存到每个相应 app 的migrations文件夹里面,并且准备如何去执行它, 作为一个分布式代码库。 每当在你的开发机器或是你同事的机器并且最终在你的生产机器上运行同样的迁移，你应当再创建这些文件。

2：实际开发中遇到的问题

但是对此我有两点异议：

1：这个度如何把握？就像我们需要史册，但是史册中如果都是个人日记堆积，这就会显得非常的冗余。 

使用场景：张三创建一个表（生成文件1提交），发现表中设计不合理，接着提交了文件2、文件3...... 李四添加了一个字段，王五删除了一个字段

这些文件都提交有必要记录到“事无巨细”？甚至一些“草稿”也提交到代码仓，进行维护。

而且不符合代码规范的其他原则：简洁、有用。

2：还有一个“头疼”的问题是--容易冲突。

特别是多人、多分支合作的时候

基于此，我想正式环境分支（master）和测试环境（dev）migration文件有必要完成一致吗？

master合并其他分支时忽略其他分支上的migration文件：master分支可自己维护一套简洁的“史册”

其他分支合并master无法忽略master上的文件，其他分支向master看齐。既减少了冲突，又解决了文件冗余问题。

二、场景模拟-文件冗余

介绍：我们基于4个分支，dev、dev_yangke、dev_yk 和 master 做场景模拟

dev分支：开发总分支。dev_yangke、dev_yk 分别为开发人员分支，对应的yango_test数据库

master分支：生成分支，对应yango数据库

1：初始化dev分支代码，生成migrations如下

2：dev_yangke：添加了一个Article模型

3：dev_yk：分别修改了ScoreModels模型的三个字段长度

 

3：Git设置

但是对于正式环境来说，这两个功能（添加article模型、修改scoreModels模型）只需要一条migration文件记录即可。

1. 创建自定义merge driver

　　git config --global merge.ours.driver true

2. 在要被merge的分支上创建.gitattributes文件,并且在文件中置顶不merge的文件名

　　echo 'DRF/api_service/migrations/** merge=ours' >> .gitattributes
　　git add .gitattributes
    git commit -m 'chore: Preserve migrations during merges' 

3. 回到要合并到的分支master,执行merge:

　　 git merge dev

 把两个开发分支合并到dev分支，