大家怎么处理开发时 Migration 一大堆，修修改改啰啰嗦嗦，同步到生产之前还得检查合并下这个问题的？

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

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

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

@Vegetable #1 啊啊啊啊啊 主要是很难受
就开发的时候 自己改着改着 就看到 0004 、0005 、0006 、0007
其中 0006 可能是撤销 0004 的 然后本地如果提交上去我就会看着很不爽
所以手动删掉从本地的 0004-0007 再重新生成一遍 0004 往生产去交

我还以为有更好的方案 可以自动帮我完成 git 和 migrate 的合体（

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

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

@Licsber 请看邮箱

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

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

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

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

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

开发时 不用那么每次改数据库都要搞一个版本 怎么方便怎么来

确保提交时的 migration 没问题就行

@songray #7 哈哈 学校邮箱吗 好像最近总是出问题 我只能收到大概好几天前的邮件
而且今年过后应该就被回收了 可以发 YWRtaW4jbGljc2Jlci5zaXRl

@yph007595 #8
@HashV2 #9
@sampeng #12
@lyxxxh2 #13 是滴 看来大家都是这样 基本上一个提交就是一个小需求 然后合并开发期间的所有 migrate

@abersheeran #10 自己的小玩具项目 都是想哪改哪 又时候还会返工

@phithon #11 上线后那必须固定下来 migrate 文件了 不然那就是真乱套了 线形历史还是要遵循的

@Licsber 其实是你的 gmail

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

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