私はこれについていくらか考えました。ここに提示されたさまざまな意見や慣行に貢献したいと思います。
ローカル移行が実際に何を表しているかを検討してください。開発データベースをローカルで操作する場合、テーブルに列などを追加したり、新しいエンティティを追加したりするときに、可能な限り最も便利な方法でデータベースを更新するために移行を使用します。
したがって、Add-Migrationは、現在のモデル（モデルbと呼びます）を以前のモデル（モデルa）と照合し、データベース内のa=>bから移行するための移行を生成します。
誰もが実際に独自のデータベースを持っていて、組織内にある種のステージ/テスト/開発/本番データベースサーバーが存在する場合、自分の移行を他の人の移行とマージしようとすることはほとんど意味がありません。これはすべて、チームがどのように設定したかによって異なりますが、本当に分散して作業したい場合は、他の人が行った変更からお互いを隔離することは理にかなっています。
さて、あなたが分散して仕事をしていて、あなたが取り組んでいるエンティティ、例えば、Personを持っているなら。どういうわけか、他の多くの人々もそれに取り組んでいます。したがって、スプリントの特定のストーリーの必要に応じて、Personのプロパティを追加および削除します（ここではすべてアジャイルに取り組んでいますね）。たとえば、社会保障番号を最初に整数にしたのは、あなたがそうではないためです。その明るいそしてそれからひもなどに。
FirstNameとLastNameを追加します。
その後、完了し、10個の奇妙な上下の移行があり（それらはただのがらくただったので、おそらく作業中にそれらのいくつかを削除しました）、中央のGitリポジトリからいくつかの変更をフェッチします。わお。あなたの同僚のボブもいくつかの名前を必要としていました、多分あなたはお互いに話し合うべきでしたか？
とにかく、彼はNameFirstとNameLastを追加しました、私は推測します...それで、あなたは何をしますか？さて、あなたはマージし、リファクタリングし、変更して、より正しい名前を付けます... FirstNameやLastNameのように、テストを実行して彼のコードをチェックしてから、中央にプッシュします。
しかし、移行についてはどうでしょうか？さて、今が中央リポジトリを移動する移行を行うときです。より具体的には、ブランチの「テスト」には、モデルa=>モデルbからのちょっとした移行が含まれています。この移行は、10の奇妙な移行ではなく、1つだけの移行になります。
私が何をしているのか分かりますか？私たちは素敵な小さなポコを使って作業しており、それらの比較が実際の移行を構成しています。したがって、移行をマージするべきではありません。私の意見では、ブランチごとの移行などを行う必要があります。
実際、マージ後にブランチで移行を作成する必要がありますか？はい、このデータベースが自動的に更新される場合は、更新する必要があります。
もう少し作業する必要があります。少なくとも、これについての私の考えです。