Background :-
背景 ：-
I am using Django 1.3. We are using South as the module for DB migration and Git SCM.
我正在使用Django 1.3。我们使用South作为数据库迁移和Git SCM的模块。
Problem:-
问题：-
What is the correct way to deal with the migrations Folder that is formed?
处理迁移的正确方法是什么形成的文件夹？
The main problem is I make changes in the DB schema in the development machine, when I upload it to the production server I have to migrate the existing schema. While doing that there is always some issue with the migration files.
主要问题是我在开发机器中对数据库模式进行了更改，当我将其上传到生产服务器时，我必须迁移现有模式。执行此操作时，迁移文件始终存在一些问题。
Should I just add the migrations folder to the gitignore ? or is there a better way to go about it ?
我应该只将迁移文件夹添加到gitignore吗？还是有更好的方法去做？
1 个解决方案
#1
21
You should add the migrations folder to your version control system and use the same files for production and development. You may run into some problems on your production system if you introduced your migrations not from the beginning and you have already existing tables.
您应该将迁移文件夹添加到版本控制系统，并使用相同的文件进行生产和开发。如果您从一开始就介绍了迁移并且已经存在表，则可能会在生产系统上遇到一些问题。
Therefore you have to fake the first migration, which normally does the same thing as syncdb did when you created your database for the first time. So when trying to apply migrations for your app for the first time on the production machine, execute manage.py migrate app_name 0001 --fake. This lets South know, that the first migration has already been applied (which already happend with syncdb) and when you run migrate again, it would continue with the following migrations.
因此，您必须伪造第一次迁移，这通常与syncdb在您第一次创建数据库时执行的操作相同。因此，在尝试在生产计算机上首次为您的应用程序应用迁移时，请执行manage.py migrate app_name 0001 --fake。这让South知道第一次迁移已经应用（已经发生了syncdb），再次运行迁移时，它将继续进行以下迁移。
#1
21
You should add the migrations folder to your version control system and use the same files for production and development. You may run into some problems on your production system if you introduced your migrations not from the beginning and you have already existing tables.
您应该将迁移文件夹添加到版本控制系统，并使用相同的文件进行生产和开发。如果您从一开始就介绍了迁移并且已经存在表，则可能会在生产系统上遇到一些问题。
Therefore you have to fake the first migration, which normally does the same thing as syncdb did when you created your database for the first time. So when trying to apply migrations for your app for the first time on the production machine, execute manage.py migrate app_name 0001 --fake. This lets South know, that the first migration has already been applied (which already happend with syncdb) and when you run migrate again, it would continue with the following migrations.
因此，您必须伪造第一次迁移，这通常与syncdb在您第一次创建数据库时执行的操作相同。因此，在尝试在生产计算机上首次为您的应用程序应用迁移时，请执行manage.py migrate app_name 0001 --fake。这让South知道第一次迁移已经应用（已经发生了syncdb），再次运行迁移时，它将继续进行以下迁移。