如題，當(dāng)本地開發(fā)環(huán)境修改 model 時，有些時候會變動好幾次，然後就產(chǎn)生了很多 migrations 檔案。
但是部署到伺服器時，伺服器端應(yīng)該怎麼執(zhí)行變更：
不上傳 migrations 文件，直接執(zhí)行 makemigrations 重新產(chǎn)生 migrations，再執(zhí)行 migrate
上傳開發(fā)時的 migrations 文件，然後直接執(zhí)行 migrate
上面兩種方法該選哪一種？為什麼？
5
0
0
小伙看你根骨奇佳，潛力無限，來學(xué)PHP伐。
按照官方的說法，應(yīng)該提交，並且在伺服器端應(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 comexs - posepose pun.
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 andrunce opment the runce same migrations on your colleagues' machines, your staging machines, and eventually your production machines.
你可以想像 migrations 相當(dāng)一個你的資料庫的一個版本控制系統(tǒng)。 makemigrations 指令負(fù)責(zé)將你的模型保存到一個遷移檔案 - 和 commits 很類似 - 同時 migrate負(fù)責(zé)將變更提交到資料庫。每個 app 的遷移檔案會儲存到每個對應(yīng) app 的「migrations」資料夾裡面,並且準(zhǔn)備如何去執(zhí)行它, 作為一個分散式程式碼庫。 每當(dāng)在你的開發(fā)機(jī)器或是你同事的機(jī)器並且最終在你的生產(chǎn)機(jī)器上運行同樣的遷移，你應(yīng)該再創(chuàng)建這些文件。
我目前是不同步到遠(yuǎn)端庫的。
因為開發(fā)過程中要頻繁的對model進(jìn)行修改，會產(chǎn)生很多migrations文件，不好控制migrate不出錯；
發(fā)布程序之前，首先確認(rèn)是否進(jìn)行model更新，如果有的話先進(jìn)行makemigrations然後migrate，由於本地已經(jīng)測試完成，所以不容易出現(xiàn)一些奇怪的同步問題。
可是在本地，添加字段然後再刪除等等一些無用的操作，最後可能數(shù)據(jù)庫沒有任何變動，那麼這些 migrations 也得提交到伺服器上再運行一遍？
