Python - Django プロジェクトの移行ディレクトリを git にコミットする必要があるか

Question

タイトルにあるように、ローカル開発環境でモデルを変更すると、モデルが数回変更され、多数の移行ファイルが生成されることがあります。

しかし、サーバーにデプロイされた場合、サーバーはどのように変更を実行する必要があります:

1. 移行ファイルをアップロードせず、makemigrations を直接実行し、移行を再生成してから、移行

を実行します。

2. 開発中に移行ファイルをアップロードし、それを直接実行します。 移行

上記 2 つの方法のうちどちらを選択すればよいですか?なぜ？

Answer 1

公式声明によると、再生成する必要はなく、サーバー側で直接送信して実行する必要がありますmigrate。

移行は、データベース スキーマのバージョン管理システムとして考える必要があります。makemigrations は、モデルの変更を個別の移行ファイルにパッケージ化する役割を果たします (コミットに似ています)。そして、移行は、それらをデータベースに適用する役割を担います。

各アプリの移行ファイルは、そのアプリ内の「migrations」ディレクトリに存在し、コードベースにコミットされ、コードベースの一部として配布されるように設計されています。これらのファイルは、開発マシン上で一度作成してから実行する必要があります。同僚のマシン、ステージング マシン、そして最終的には実稼働マシンでも同じ移行を行うことができます。

中国語翻訳:

移行はデータベースのバージョン管理システムと考えることができます。 makemigrations コマンドは、コミットと同様に、モデルの変更を移行ファイルに保存する役割を果たします。一方、migrate は、変更をデータベースにコミットする役割を果たします。

各アプリの移行ファイルは、対応する各アプリの「migrations」フォルダーに保存され、実行方法は分散コードベースとして用意されます。 開発マシンまたは同僚のマシン、そして最終的には運用マシンで同じ移行を実行するたびに、これらのファイルを再度作成する必要があります。

Answer 2

リポジトリに送信することをお勧めします。

Answer 3

現在、リモート ライブラリと同期していません。
開発プロセス中にモデルを頻繁に変更する必要があるため、多くの移行ファイルが生成され、エラーなく移行を制御するのは困難です。
プログラムを公開する前に、まずモデルが更新されているかどうかを確認してください。 makemigrations を実行してから移行します。ローカルでテストされているため、奇妙な同期の問題は発生しません。

Answer 4

移行で新しく生成された変更を送信する前に削除し、移行を再作成してからリポジトリを送信してみてはいかがでしょうか

Answer 5

しかし、ローカルでフィールドを追加して削除するなどの操作は、最終的にはデータベースに変更がない可能性があるため、これらの移行もサーバーに送信して再度実行する必要があります。