異なるマシンで別々に実行すると、Djangoの移行でエラーが発生する

Question

私たちはDjangoプロジェクトに取り組んでいる開発者チームです。私たちはdjangoの移行に関する問題に直面しています。ある開発者がモデルを変更し、マイカマイグレーション>マイグレーションシーケンスを実行すると、migrationsディレクトリにいくつかのsqlsが生成されます。他の開発者がコードをプルして同じシーケンスを実行すると、コードが悪い状態になります。この問題を解決するために、マイグレーションディレクトリをローカルでクリアしています。すべてのデータをクリアすることもあります。私たちが間違って何をしているのか分かりません。 djangoの移行を使用する正しい方法を提案してください。

注 - 私たちはすべて、ローカルマシンで別のDBインスタンスを使用します。あなたは、たとえば、移行ファイルをプッシュした後

Answer 1

makemigrationsはちょうど、バージョン管理下に0001_initial.pyをファイル

By running makemigrations, you’re telling Django that you’ve made some changes to your models (in this case, you’ve made new ones) and that you’d like the changes to be stored as a migration.

Migrations are how Django stores changes to your models (and thus your database schema) - they’re just files on disk. You can read the migration for your new model if you like; it’s the file polls/migrations/0001_initial.py.

を作成します。他の開発者は、単にバージョン管理について

python manage.py sqlmigrate your_app 0001 # to see what happen 

python manage.py migrate your_app 0001 

詳細を実行し、ファイルを引っ張っ：

Version control

Because migrations are stored in version control, you’ll occasionally come across situations where you and another developer have both committed a migration to the same app at the same time, resulting in two migrations with the same number.

Don’t worry - the numbers are just there for developers’ reference, Django just cares that each migration has a different name. Migrations specify which other migrations they depend on - including earlier migrations in the same app - in the file, so it’s possible to detect when there’s two new migrations for the same app that aren’t ordered.

When this happens, Django will prompt you and give you some options. If it thinks it’s safe enough, it will offer to automatically linearize the two migrations for you. If not, you’ll have to go in and modify the migrations yourself - don’t worry, this isn’t difficult, and is explained more in Migration files below.