問(wèn)題描述

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

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

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

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

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

問(wèn)題解答

按照官方的說(shuō)法，應(yīng)該提交，并且在服務(wù)器端應(yīng)該直接執(zhí)行 migrate，無(wú)需再次生成。

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)一個(gè)你的數(shù)據(jù)庫(kù)的一個(gè)版本控制系統(tǒng)。makemigrations 命令負(fù)責(zé)保存你的模型變化到一個(gè)遷移文件 - 和 commits 很類似 - 同時(shí) migrate負(fù)責(zé)將改變提交到數(shù)據(jù)庫(kù)。

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

建議提交到版本庫(kù)中。

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

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

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