[解決済み] Django の移行ファイルは .gitignore ファイルに追加した方が良いですか？

質問

の中に Django のマイグレーションファイルを追加すべきでしょうか？ .gitignore ファイルを作成できますか？

最近、マイグレーションのコンフリクトによるgitの問題が多発しているのですが、マイグレーションファイルを無視するようにマークすべきかどうか悩んでいます。

もしそうなら、アプリにあるすべてのマイグレーションを、どのようにして .gitignore ファイルを作成します。

解決方法は？

引用元 Django migrations ドキュメント :

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

このプロセスに従えば、マイグレーションファイルでマージの競合が発生することはないはずです。

バージョン管理ブランチをマージするとき、同じ親マイグレーションに基づく複数のマイグレーションが存在する状況に遭遇することがあります。たとえば、異なる開発者が同時にマイグレーションを導入した場合です。この状況を解決する方法のひとつが マージマイグレーション . 多くの場合、これはコマンドで自動的に行うことができます。

./manage.py makemigrations --merge

これは、現在のすべてのヘッドマイグレーションに依存する新しいマイグレーションを導入するものです。もちろん、これは head migrations の間に競合がない場合にのみ動作し、その場合は問題を手動で解決する必要があります。

ここで何人かの人が提案したことを考えると はいけません。 マイグレーションをバージョンコントロールにコミットする理由を説明したいと思います。 すべき するのです。

まず、本番システムに適用されたマイグレーションの記録が必要です。本番環境に変更を導入し、データベースを移行する場合、現在の状態の記述が必要です。各本番データベースに適用されたマイグレーションのバックアップを個別に作成することもできますが、これは不必要に面倒なように思われます。

第二に、マイグレーションにはしばしばカスタムで手書きのコードが含まれます。を使用して自動的に生成することは常に可能とは限りません。 ./manage.py makemigrations .

3つ目は、マイグレーションはコードレビューに含めるべきだということです。これらは本番システムに対する重要な変更であり、うまくいかないことがたくさんあります。

つまり、本番データを大切にするのであれば、マイグレーションをバージョン管理でチェックしてください、ということですね。