問題描述

如題，本地開發環境修改 model 時，有些時候會變動好幾次，然后就生成了很多 migrations 文件。

但是部署到服務器時，服務器端應該怎么執行變動：

不上傳 migrations 文件，直接執行 makemigrations 重新生成 migrations，再運行 migrate

上傳開發時的 migrations 文件，然后直接執行 migrate

上面兩種方法該選哪一種？為什么？

問題解答

按照官方的說法，應該提交，并且在服務器端應該直接執行 migrate，無需再次生成。

You should think of migrations as a version control system for your database schema. makemigrations is responsible for packaging up your model changes into inpidual migration files - analogous to commits - and migrate is responsible for applying those to your database.

The migration files for each app live in a “migrations” directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues’ machines, your staging machines, and eventually your production machines.

中文翻譯：

你可以想象 migrations 相當一個你的數據庫的一個版本控制系統。makemigrations 命令負責保存你的模型變化到一個遷移文件 - 和 commits 很類似 - 同時 migrate負責將改變提交到數據庫。

每個 app 的遷移文件會保存到每個相應 app 的“migrations”文件夾里面,并且準備如何去執行它, 作為一個分布式代碼庫。 每當在你的開發機器或是你同事的機器并且最終在你的生產機器上運行同樣的遷移，你應當再創建這些文件。

建議提交到版本庫中。

我目前是不同步到遠程庫的。因為開發過程中要頻繁的對model進行修改，會生成很多migrations文件，不好控制migrate不出錯；發布程序之前，首先確認是否進行model更新，如果有的話先進行makemigrations然后migrate，由于本地已經測試完成，所以不容易出現一些奇怪的同步問題。

為什么不提交之前把migrations里新生成的多次變動刪了 重新makemigrations一下然后提交版本庫呢

可是在本地，添加字段然后再刪除等等一些無用的操作，最后可能數據庫沒有任何變動，那么這些 migrations 也得提交到服務器上再運行一遍？