在團隊環境中處理遷移時，當多位開發者同時加入遷移時，可能會產生各種問題;請注意，遷移不只是 SQL 腳本，還包含遷移時模型的快照。
舉例來說，假設開發者 A 和 B 同時建立工作分支，並在各自分支中產生遷移。 如果開發者 A 合併了他們的分支，然後開發者 B 也合併了，最新的遷移（開發者 B 的）會有一個上下文快照，不會包含開發者 A 遷移的變更。 這可能導致後續遷徙中各種形式的腐敗。
因此，強烈建議提前協調，並盡量避免同時處理多個分支的遷移。
遷徙形成有序的序列。 每個遷移的設計元資料代表序列中該點的模型，並在遷移移除時使用。 不要透過排序或重新命名檔案來解決平行遷移：後續遷移仍會包含不包含其他分支變更的元資料。
偵測分岔遷移樹
備註
此功能將於 EF Core 11 預覽版 3 起引入。
從 EF 11 開始，模型快照將記錄最新遷移的 ID。 這表示如果兩位開發者各自在不同的分支建立遷移，合併這些分支會在模型快照檔案中產生原始碼控制衝突——因為兩個分支都會修改最新的遷移 ID。 這個衝突是一個重要訊號：它告訴你遷移樹已經分岔，必須丟棄其中一棵才能繼續前進。
解決這個問題，請依照以下「 解析分歧遷移樹 」中的步驟操作：中止合併、移除遷移（保留模型變更）、合併隊友的變更，然後重新加入遷移。
EF Core 10 及更早版本不會在模型快照中記錄最新的遷移 ID，因此原始碼控制系統可能會合併快照而不會報告此衝突。 遷移樹仍然分歧，必須用相同的工作流程來解決。
解析分歧遷移樹
如果在合併分支時偵測到遷移樹有分歧，請透過重建遷移來解決。 請遵循下列步驟：
- 中止合併，並在合併前回到你的工作目錄。
- 移除你的遷移，但保留產生遷移的模型變更。 原始碼控制可僅移除產生的遷移檔案並還原遷移前快照。
- 把你隊友的變更合併到你的工作目錄裡。
- 重新新增遷移，讓它基於合併後的模型快照。
完成此步驟後，你的遷移將無縫地整合在其他分支新增的所有遷移之上，其上下文快照將包含所有先前的變更。 你的遷移現在可以安全地與團隊其他成員分享。
不要在平行遷移已經合併成無效序列後執行 dotnet ef migrations remove （或 Remove-Migration）。 該指令會恢復由前一個遷移設計者元資料所代表的模型，該中繼資料可能不包含其他分支的變更。 使用原始碼控制回到合併前的連貫狀態，然後依照上述步驟操作。
還原原始碼控制中的遷移變更
還原原始碼控制提交不會改變任何資料庫。 在移除遷移程式碼前，請選擇以下方法之一：
- 如果遷移尚未套用到共享資料庫，請移除遷移並還原模型變更。
- 若遷移已套用，請在遷移代碼尚存時將資料庫遷移至較早的遷移，或部署新的修正遷移。 在回滾過程中，保持應用程式與資料庫部署的相容性。
不要移除仍記錄在共享資料庫中的遷移來源。 如果程式碼已經被還原，請檢查或還原包含遷移的提交，產生並測試回滾，然後提交一個連貫的遷移序列。
