Djangoにおけるmake migrationsはどのタイミングで実施しどう管理すべきですか？

Question

前提

• Djangoを勉強しています
• Viewの更新時にpython3 manage.py makemigrationsを実行し、DBのスキーマ変更用のファイルを作成しています

お伺いしたいこと

1. viewでカラムを追加し、あとでそれを削除すると無駄に000X_auto_yyyymmdd_hhmm.pyが作成されます。例えばXXカラムを追加、それを削除、またXXカラムを追加、再び削除とすると4ファイルも生成されますが、結局最後まで適用するとXXカラムがないだけの状態に戻ります。declarative(宣言的)ではなくprocedural(手続的)的な動きをしているため非常に使いづらさを感じるのですが、現場では000X_auto_yyyymmdd_hhmm.pyが大量にできることに対して何か工夫やアプローチをされることはありますか？

2. チームで開発する場合python3 manage.py makemigrationsはどのタイミングで実施してGitにCommitしていますか？（Modelを修正した人がローカルで実行してcommitに含める？それともCIの中で行う？など）

Answer 1

1例でしかない事を最初に記載しておきます。

1. 現場では000X_auto_yyyymmdd_hhmm.pyが大量にできることに対して何か工夫やアプローチをされることはありますか？

機能単位やリリース単位でmigrationファイルを作り直しております。
具体的には、releaseブランチが既に本番環境で動いているブランチだとすると、そのブランチとリリース対象のブランチを比較し、rm -> makemigrations という感じです。
ただ、実際には自動生成のコードだけで間に合わない事（データの置換など）もあるため、手動マージも行います。
ここは通常のプルリクエストで行っておりますので、レビューやCIなどが動くことになります。

1. どのタイミングで実施してGitにCommitしていますか？

機能開発時のコード追加と同じタイミングになります。
全体的に1と絡む回答になりますが、PRを使用している場合、任意の単位で開発者はコミットされますが、最終的にマージされる際にはまとまっています。（質問1の例だと、追加削除追加削除なので結局何も行われずmigrationファイル自体がコミットされない）

（Modelを修正した人がローカルで実行してcommitに含める？それともCIの中で行う？など）

「Modelを修正した人がローカルで実行してcommitに含める」こちらになります。
より正確に言えば、migrationファイルの作成はmodel作成者の責務であり、それをmakemigrationを使うかはどうかは場合によります。