.gitignoreファイルにDjango移行ファイルを追加する必要がありますか？
Django移行ファイルを.gitignoreファイルに追加する必要がありますか？
私は最近、移行の競合のために多くのgit問題を取得しており、移行ファイルを無視としてマークする必要があるかどうか疑問に思っていました。
もしそうなら、アプリにある移行をすべて追加し、.gitignoreファイルに追加するにはどうすればよいですか？
Django移行ドキュメント から引用：
各アプリの移行ファイルは、そのアプリ内の「移行」ディレクトリに存在し、そのコードベースにコミットされ、その一部として配布されるように設計されています。開発マシンで一度作成してから、同僚のマシン、ステージングマシン、そして最終的に本番マシンで同じ移行を実行する必要があります。
このプロセスに従えば、移行ファイルでマージの競合が発生することはありません。
現在発生している問題を緩和するには、どのリポジトリまたはブランチに正式バージョンの移行ファイルがあるかを指定し、 gitの属性メカニズム を使用してこれらのファイルのマージ戦略「ours」を指定する必要があります。これにより、これらのファイルへの外部変更を常に無視し、ローカルバージョンを優先するようにgitに指示します。
番号。
私はこれを何度も繰り返してきましたが、私の人生では、レポジトリで移行が必要なケースを見つけることはできません。
ご覧のとおり、スキーマの最終的なレコードはmodels.pyです。変更をマージして他の誰かがそれをプルすると、makemigrationsおよびmigrateを実行したときにすべてが正しくなります。移行のための「私たち」の戦略を定義する必要はありません。
ロールバックする必要がある場合は、modelsを元に戻して移行します。すべて問題なく、問題ありません。
フィールドが既に存在するなどの不満はありません。
仕事に取りかかる前に、他の開発者の移行ファイルをマージする必要があるという利点がある特定のケースを誰かに教えてもらえないかと思います。私はドキュメントがそうすべきだと言っていることを知っているので、そうだと思います。しかし、私は1つにも会ったことがありません。
誰でも？
以下のプロセスに従うことができます。
makemigrationsをローカルで実行すると、移行ファイルが作成されます。この新しい移行ファイルをリポジトリにコミットします。
私の意見では、makemigrationsを実稼働環境で実行しないでください。本番環境でmigrateを実行すると、ローカルからコミットした移行ファイルから移行が適用されていることがわかります。これにより、すべての競合を回避できます。
IN LOCAL ENV、移行ファイルを作成するには、
python manage.py makemigrations
python manage.py migrate
次に、これらの新しく作成されたファイルをコミットします。次のようなものです。
git add app/migrations/...
git commit -m 'add migration files' app/migrations/...
IN PRODUCTION ENV、以下のコマンドのみを実行します。
python manage.py migrate
2018年のドキュメント、Django 2.0からの引用。 （2つの別個のコマンド= makemigrationsおよびmigrate）
移行を作成して適用するための個別のコマンドがある理由は、バージョン管理システムに移行をコミットし、アプリに同梱するためです。開発を容易にするだけでなく、他の開発者や本番環境でも使用できます。
私は想像できませんなぜ移行を何らかの方法で編集していない限り、競合が発生するでしょうか？通常、それはひどく終わります。誰かがいくつかの中間コミットを逃すと、正しいバージョンからアップグレードできなくなり、データベースのコピーが破損します。
私が従うプロセスは非常に単純です-アプリのモデルを変更するたびに、移行もコミットします。そして、移行は変更されません-モデルに別の何かが必要な場合は、モデルを変更し、変更とともに新しい移行をコミットします。
グリーンフィールドプロジェクトでは、多くの場合、リリース時に移行を削除し、0001_移行で最初からやり直すことができますが、運用コードがある場合はできません（移行を1つにまとめることはできます）。
通常使用されるソリューションは、マスターに何かをマージする前に、開発者がリモートの変更をプルする必要があるということです。移行バージョンに競合がある場合は、彼の名前をlocal migration（リモートの移行は他の開発者によって、場合によっては運用環境で実行されています）からN + 1に変更する必要があります。
開発中は、移行をコミットしないだけでかまいません（ただし、無視しないで、addしないでください）。しかし、運用環境に移行したら、スキーマをモデルの変更と同期させるために必要になります。
次に、ファイルを編集し、dependenciesを最新のリモートバージョンに変更する必要があります。
これは、Django移行および他の同様のアプリ（sqlalchemy + alembic、RoRなど）で機能します。
開発、ステージング、および本番環境用に個別のDBがある場合、移行を無視します。開発者向け目的ローカルsqlite DBを使用して、ローカルで移行を試すことができます。 4つの追加ブランチを作成することをお勧めします。
マスター-移行せずに新しいコードをきれいにします。このブランチには誰も接続していません。コードレビューのみに使用
開発-毎日の開発。プッシュ/プルが受け入れられます。各開発者はsqlite DBに取り組んでいます
Cloud_DEV_env-リモートクラウド/サーバーDEV環境。プルのみ。コードの展開とDevデータベースのリモート移行に使用される、マシン上でローカルに移行を維持します
Cloud_STAG_env-リモートクラウド/サーバーSTAG環境。プルのみ。 Stagデータベースのコード展開とリモート移行に使用される、マシン上でローカルに移行を維持します
Cloud_PROD_env-リモートクラウド/サーバーDEV環境。プルのみ。コードの展開とProdデータベースのリモート移行に使用されるマシン上の移行をローカルに保持します
注：2、3、4-移行はリポジトリに保持できますが、プルリクエストのマージの厳格なルールがあるはずです。そのため、展開を担当する人を見つけることにしました。 -er。モデルに変更があるたびに、彼はリモートDB移行を保持します。
競合を無視するのではなく、gitワークフローを調整する必要があるように感じます。
理想的には、すべての新機能は別のブランチで開発され、プルリクエストでマージされます。
競合がある場合、PRをマージできません。したがって、自分の機能をマージする必要があるユーザーは、競合を解決する必要があります（移行を含む）。
短い答えレポジトリでの移行を除外することを提案します。コードのマージ後、./manage.py makemigrationsを実行するだけで設定は完了です。
長答移行ファイルをレポに入れるべきではないと思います。他の人の開発環境や他の製品およびステージ環境の移行状態を台無しにします。 （例については、Sugar Tangのコメントを参照してください）。
私の観点では、Django移行の目的は、以前のモデルの状態と新しいモデルの状態との間のギャップを見つけ、そのギャップをシリアル化することです。コードのマージ後にモデルが変更された場合は、makemigrationsを実行してギャップを見つけることができます。同じものを自動的にバグフリーで実現できるのに、なぜ他の移行を手動で慎重にマージしたいのですか？ Djangoドキュメンテーション 言う、
それら*（移行）*は、ほとんど自動になるように設計されています
;そのままにしてください。移行を手動でマージするには、他の人が何を変更したか、および変更の依存関係を完全に理解する必要があります。それは多くのオーバーヘッドとエラーが発生しやすいです。したがって、モデルファイルの追跡で十分です。
ワークフローに関する良いトピックです。私は他のオプションを受け入れています。
Gitに多数の移行ファイルがあるのは面倒です。移行フォルダーには、無視してはならないファイルが1つしかありません。そのファイルはinit。pyファイルです。無視すると、pythonはディレクトリ内のサブモジュールを検索しなくなるため、モジュールをインポートしようとしても失敗します。したがって、質問はinit。py以外のすべての移行ファイルを無視する方法ですか？解決策は次のとおりです。「0 * .py」を.gitignoreファイルに追加すると、完璧に機能します。
これが誰かを助けることを願っています。