做项目的时候尝试使用版本来更新迭代
所以就去看了版本迁移的相关文章，发现如果是数据库迁移的话，不能直接一步登天，要不断的更新，从0.0.1到0.0.5，不能着急直接0.0.1——0.0.5，要0.0.1——0.0.2.......0.0.4——0.0.5
同时其他要注意的是
迁移过之后，我们会发现在数据库中多了迁移模型的数据表，查看相应表也可以看到我们所建立的字段和类型。
但也多了几张表,其中一张便是django_migrations,这张表即是记录我们在每次执行迁移操作时记录的迁移文件的数据表。具体记录的是模块和与其对应的迁移文件名。
在我们协同开发过程中，遇到模型复用和更新迭代是最常见的事情，有时候我们会多次数据库迁移来对旧表进行修改。但随着迭代版本的增加太多的迁移文件有时却让自己很烦，在版本控制时也会产生一些冲突和意想不到的bug。那么有时候就需要重新迁移文件，所以在删除迁移文件migrations的同时还要清楚django_migrations表里的记录。来再次重新迁移。
那么通过这一点规律来做一点小事情。
有时候，在版本控制的时候，每个人的操作习惯不太相同，有些开发者喜欢不提交迁移文件，而在服务器拉下代码后进行迁移操作。但当项目上线之前跑量的过程中却清除了数据库中的数据，再次提交migrate操作时就会出现迁移数据表已经存在的错误信息。（当然，这并不影响服务器的运行，也不会有任何异常，只是一直会有个报错而已罢了），干掉错误信息！一张两张表可能我们会选择删除表之后重新迁移，但是如果模型过多删除表的操作也相应增多（况且，有一些表的数据我还不想全部删除）。
所以我们要去看看官方文档怎么说的
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”文件夹里面,并且准备如何去执行它, 作为一个分布式代码库。 每当在你的开发机器或是你同事的机器并且最终在你的生产机器上运行同样的迁移，你应当再创建这些文件。
其实无非是集中情况而已罢了
如果开发环境和生产环境使用同一数据库，
那么完全不用考虑这个问题，只要对django_migrations表进行备份，不要误删就好了。在提交代码时提交迁移文件，在服务器上也不用执行相应的迁移操作了。
如果 开发环境和生产环境使用不同数据库，
那么这个问题其实也很好解决，提交迁移文件之后直接在服务器进行迁移操作。或者不提交在服务器上自主生成迁移文件，再进行迁移操作。那么在随着版本迭代的过程中，开发环境的迁移文件也许会比生产环境的迁移文件多得多，那么就产生了也许在不同开发者的开发设备中版本不统一问题。再加上每人操作习惯不同，不提交迁移文件就会产生在服务器端重新迁移，对于日后的版本控制相当不友好。
所以，其实对于迁移文件也是应该直接提交至远程仓库的。
