git本身不管理数据库结构变更，但可通过版本化幂等sql脚本实现多分支协同；禁止直接跟踪二进制数据目录，应按环境分目录组织迁移文件，严格遵循if not exists、显式条件dml、校验和比对及字典序执行等规范。
git 本身不管理数据库结构变更，但多分支环境下用它控制数据库脚本是可行的——前提是脚本必须是**幂等、可重放、带明确版本标识**的纯文本文件（如 .sql），且团队严格遵守“一个分支只提交对应环境的变更”。
为什么不能直接 git add /var/lib/postgresql/data？
数据库二进制数据目录不是代码，git 无法 diff、无法 merge、无法回滚到某次“事务”。强行跟踪会导致：
• .git 仓库体积暴增（几 GB）
• git status 卡死或报错
• 每次 git pull 后需手动重启服务才能生效
• 不同分支的 pg_xlog 或 base 目录冲突不可解
正确的脚本组织方式：按分支+环境隔离
把数据库变更当作“迁移任务”来管理，而不是“数据库状态快照”。推荐目录结构：
db/migrations/
├── dev/
│ ├── 001_init.sql
│ └── 002_add_user_index.sql
├── staging/
│ └── 001_init.sql
└── prod/
├── 001_init.sql
└── 002_add_audit_log.sql
-
dev/分支只允许修改db/migrations/dev/下的脚本，git push前必须通过本地psql -f验证语法 -
staging和prod目录只允许main或release/*分支修改，且每次提交必须附带git commit -m "db: prod add audit_log table [ticket-123]" - 禁止跨目录复制脚本——
dev/003_fix_null.sql不能直接拷进prod/，必须走git cherry-pick或重新生成带 prod 前缀的版本
git merge 时 SQL 脚本冲突怎么处理？
冲突不是出现在 SELECT 语句里，而是出现在「谁先建表」「谁先删字段」这类逻辑顺序上。实际遇到的典型错误：
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
-
ERROR: relation "users" already exists—— 两个分支都写了CREATE TABLE users -
column "email" does not exist—— A 分支删了字段，B 分支还在用 -
duplicate key value violates unique constraint—— 两个分支都插入了相同INSERT INTO config VALUES (1, 'mode', 'dev')
解决办法只有两条硬规则：
- 所有 DDL 必须加
IF NOT EXISTS（PostgreSQL）或CREATE TABLE IF NOT EXISTS - 所有 DML 必须用
INSERT ... ON CONFLICT DO NOTHING或UPDATE ... WHERE显式条件，禁用无条件INSERT - 每次
git merge后，必须在本地用psql -v ON_ERROR_STOP=1 -f db/migrations/dev/*.sql全量重放验证
上线前如何确保 prod 脚本和分支完全一致？
靠人眼核对 git log --oneline db/migrations/prod/ 和线上数据库当前版本号是不可靠的。真正有效的做法是：
- 在 CI 流水线中加入一步：
sha256sum db/migrations/prod/*.sql | sort | sha256sum，把结果写入部署包元数据 - 生产服务器上执行部署脚本时，自动比对当前
/opt/app/db/migrations/prod/的 checksum 和包内记录值 - 用
git describe --tags --abbrev=0给每个发布打 tag，例如v2.4.1-db-prod-20260723，tag 名必须含-db-prod-标识
最易被忽略的一点：数据库脚本的执行顺序依赖文件名前缀（如 001_），但 git ls-files 返回顺序不保证字典序——必须用 find db/migrations/prod/ -name "*.sql" | sort 显式排序后再执行。
