4

プロジェクトの master ブランチでは、django アプリの 1 つの移行は次のようになります。

# ...
(*) 0022_datamigration_1
(*) 0023_datamigration_2
(*) 0024_datamigration_3
(*) 0025_datamigration_4

ご覧のとおり、これらの移行は既に本番システムに適用されています。私のブランチでは、かなり多くの移行を必要とする機能を開発しました。

(*) 0022_datamigration_1
( ) 0023_my_schemamigration_1
(*) 0023_datamigration_2
( ) 0024_my_datamigration_1
(*) 0024_datamigration_3
(*) 0025_datamigration_4
( ) 0025_my_datamigration_2
( ) 0026_my_schemamigration_2
# ... some more not yet applied schemamigrations
( ) 0030_my_datamigration_x

これも本番データベースの「移行履歴」ですが、マスターが変更されている間に機能の作業を同時に行ったため、一部の移行は既に適用されており、現在は履歴にこれらの「ギャップ」があります。南は実行してそれらを適用することを拒否しますpython manage.py migrate my_app

 ! Migration my_app:0024_datamigration_3 should not have been applied before my_app:0024_my_datamigration_1 but was.
 ! Migration my_app:0023_datamigration_2 should not have been applied before my_app:0023_my_schemamigration_1 but was.

これらの「移行ギャップ」を取り除くにはどうすればよいですか (Google に間違ったキーワードを入力していると思います)。少なくとも、移行はすべて異なるモデルに影響するはずなので、何とかできると思います。

4

1 に答える 1

3

まず、新しいコードをコミットする前に移行を統合すると、頭痛の種が大幅に軽減されます。開発中に 0023、0024、0025 という番号のスキーマ移行を生成したとします。何かをコミットする前に、変更を開始する直前の移行 (この場合は 0022) にロールバックする必要があります。

python manage.py migrate someapp 0022

次に、3 つの移行を削除し、最後に新しい schemamigration を生成します。

python manage.py schemamigration --auto someapp

これで、行ったすべての変更を組み合わせた 1 つの移行 0023 ができました。これにより、移行を残りの部分にマージすることがはるかに簡単になります。

次に、マージを行うと、すでに 0023 が存在する可能性があります。

0023_someone_elses_migration.py
0023_my_migration.py

自分の番号を最大値よりも 1 つ大きい名前に変更するだけです (0030 までの移行がある場合は、自分の番号を 0031 に変更します)。次に、マージされたコードをコミットします。

ただし、一般的には、コードベースのどの部分についても、常に 1 人の開発者だけが作業することを、適切な開発プラクティスとして規定する必要があります。常に可能であるとは限りませんが、一般的に、「someapp」の機能に取り組んでいて、「someapp」の別の機能のバグ修正が必要な場合は、あなたがそれを行うべきです。変更がまったく別のブランチで行われる場合でも、別の開発者が手掛かりを持たないのに対し、作業中の他のものに変更をマージすることで補償することができます.

于 2012-06-21T20:06:15.793 に答える