問題描述

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

但是部署到服務(wù)器時，服務(wù)器端應(yīng)該怎么執(zhí)行變動：

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

上傳開發(fā)時的 migrations 文件，然后直接執(zhí)行 migrate

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

問題解答

按照官方的說法，應(yīng)該提交，并且在服務(wù)器端應(yīng)該直接執(zhí)行 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 相當(dāng)一個你的數(shù)據(jù)庫的一個版本控制系統(tǒng)。makemigrations 命令負責(zé)保存你的模型變化到一個遷移文件 - 和 commits 很類似 - 同時 migrate負責(zé)將改變提交到數(shù)據(jù)庫。

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

建議提交到版本庫中。

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

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

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