1

1

是正常流程，不优雅的是你将数据库改来改去，而你也在最后通过自己的手段压缩了变更，别人看起来就挺优雅的了。
不过这个流程挺容易出事故的，轻则发布失败，重则数据丢失，多人合作很难要求别人整理 migrations 。

2

1

有些语言框架你还得手动写 migration 呢。。比如写 go 的时候用 sqlc

3

1

db 修改我都是手写 sql ，原来还有自动的……

4

5

1

不用 Django, 但是用 Rails.
许多公司的 devops 流程是表结构在「开发设计评审」阶段就确认, 后续修改都要和 code review 的同事对齐. 即便是开发阶段也是不能随便修改.
自己的项目那就随便拉, 只要能跑起来就无所谓.
只有带着镣铐跳舞才能优雅, 这就是为啥公司会有一堆条条框框, 你把镣铐解除了那自然优雅不了辣...
说起来, njit 前辈?

6

@songray #5 哈哈 自己的小项目 都是没有这些条条框框
直接表结构觉得设计的不对就上手改
是滴 学弟嘛？可以加我

8

1

多人开发 django 项目，migrations 文件夹不提交 git ，每次合并到 master 的时候，重新生成 migrations 文件

9

1

@Licsber #4 我就是这样处理的，但是我是按照需求来进行的，比如一个需求产生了 0004 0005 0006 我就三合一再提交，要注意的几个点，一得默认值什么的检查仔细点，二是记得同步 django_migrations 那张表

10

1

奇怪的强迫症。模型字段不仔细思考就改，是你这个问题的根源。

11

1

上线前我也会这样，上线后就只正经用 migration 来改数据库了。

12

1

这也是我一开始碰到的疑问。。后来一看，就 3-4 个人。。我脑子有包有个变更就+1 版本。直接 new 一个版本，在这个版本上改对为止。一次迭代有且只有一个版本

13

1

14

16

1

测试环境开发完了，把生成的 migrate 文件全删了重新生成，这样只会有一个 migrate 文件，这个不是基操了吗？

17

@qsnow6 #15 觉得很麻烦 觉得会有一种更优雅的方案 没想到大家都是这样哈哈哈