従来の知識では、データベースの移行はVCS内に保持する必要があるようです。そうすれば、データベースが行ったすべての変更の記録があります。
だが...
古い移行を使用することの用途は何ですか?私は自分が古いバージョンのdbに戻っているのを実際には見ていません。それらをVCSから除外し、他のすべての移行キューと同期を維持する必要のないすべてのマシンに移行キューを作成する方が簡単ではないでしょうか。
従来の知識では、データベースの移行はVCS内に保持する必要があるようです。そうすれば、データベースが行ったすべての変更の記録があります。
だが...
古い移行を使用することの用途は何ですか?私は自分が古いバージョンのdbに戻っているのを実際には見ていません。それらをVCSから除外し、他のすべての移行キューと同期を維持する必要のないすべてのマシンに移行キューを作成する方が簡単ではないでしょうか。
古い移行を維持するのが無駄だと思うなら、移行を理解していません。移行により、変更をロールバックできます。あなたはそれをすることを想像しないかもしれませんが、それは必要かもしれません。完全な移行履歴により、コラボレーションチームは、開始時のバージョンに関係なく、同期を維持できます。
ゴミ箱に入れてやり直すことは、サウスでできる最悪のことの1つです。全員にsouth_migrationhistoryテーブルにアクセスしてクリアし、既存のすべての移行を削除して新しいinit移行を作成するように明示的に指示しない限り、他の開発者を完全に台無しにします。
要するに。移行はVCSに残しておきます。これにより、どの時点からでもプロジェクトに参加するすべての人がデータベースを現在のバージョンにすばやく移行できるようになります。それらを一掃しないでください、それらは何も傷つけません、そしてあなたはそうすることによって他の協力者のために面倒を作成します。
古い移行を維持することにはほとんど意味がないと思いますが、害がない場合でも、プロジェクトで未使用のコードは好きではありません。
southのような移行システムを使用すると、開発中に大いに役立ちますが、統合された機能/変更に関する古いスキーマ移行はおそらく必要ないでしょう(そして、VCSで利用可能なPythonコードのモデル変更がまだある場合)。
ときどき、1回の初期移行ですべての移行をゴミ箱に移動して再作成し、新しい移行の収集を再開します。
移行をVCSの外部に維持することはお勧めできません。問題が発生しない場合は、開発が確実に遅くなる可能性があります。
編集:クリーンアッププロセスでは、チームがこの再編成を認識している(そして移行履歴テーブルをクリアしている)ため、すべての開発者/ユーザーに簡単に連絡できない場合は、そうすることはお勧めしません。