2. Git 基础回顾：Git 的核心概念——为数据库迁移版本控制打下基础
在深入数据库迁移的版本协同之前，必须牢固掌握 Git 的五大核心概念：仓库、提交、分支、合并 和 标签。这些概念构成了所有 Git 工作流的基础，也是后续管理数据库迁移脚本（DDL/DML）版本演进的基石。
2.1 仓库（Repository）—— 版本控制的容器
仓库是 Git 存储所有文件历史记录、元数据和配置信息的地方。对于数据库迁移项目，一个仓库通常对应一个数据库项目或一个微服务的数据库变更集合。
| 仓库类型 | 说明 | 数据库迁移场景 |
|---|---|---|
| 本地仓库 | 开发者本机 .git 目录，包含完整历史 |
开发者在本地编写、测试迁移脚本 |
| 远程仓库 | 托管在服务器（GitHub/GitLab）上的共享仓库 | 团队协作、代码 Review、CI/CD 触发 |
| 裸仓库 | 没有工作目录，仅存储历史（--bare） |
服务端中心仓库，用于团队推送和拉取 |
实践建议： 建议为每个数据库项目（如
order-service-db）单独创建一个仓库，并将所有迁移脚本（如 V1__create_users.sql）集中管理，避免与应用程序代码混在一起导致权限混乱。
2.2 提交（Commit）—— 变更的快照
提交是 Git 的核心操作，它记录了一次文件状态的快照。每个提交都有一个唯一的 SHA-1 哈希值，并包含作者、时间戳和提交信息。在数据库迁移中，一个提交通常对应一个原子性的数据库变更。
# 创建一个包含数据库迁移脚本的提交
git add migrations/V2__add_email_column.sql
git commit -m "feat: 为 users 表添加 email 字段"
# 查看提交历史
git log --oneline
# 输出示例：
# a1b2c3d feat: 为 users 表添加 email 字段
# e4f5g6h fix: 修正 V1 迁移脚本中的数据类型
提交原则（数据库迁移专用）：
- 原子性： 一个提交只包含一个逻辑变更（如：只新增一张表，或只修改一个字段）。
- 可回滚： 每个提交应包含对应的回滚脚本（如
V2__add_email_column.sql对应U2__drop_email_column.sql）。 - 信息清晰： 提交信息必须说明“为什么改”和“改了什么”，例如
fix: 将 users.name 长度从 50 扩展到 100 以支持国际姓名。
2.3 分支（Branch）—— 并行开发的轨道
分支让开发者可以在独立的环境中工作，互不干扰。对于数据库迁移，分支策略直接决定了团队如何并行开发、如何隔离风险。
数据库迁移分支陷阱： 避免在多个长期运行的分支上同时修改同一张表的结构。例如，分支 A 在
users 表添加了 age 字段，分支 B 删除了 users 表的 birthday 字段，合并时极易产生冲突或导致数据丢失。建议使用“短生命周期分支”策略，并频繁同步 main 分支。
2.4 合并（Merge）—— 变更的整合
合并是将一个分支的变更应用到另一个分支的过程。在数据库迁移场景中，合并需要特别谨慎，因为数据库状态是“有状态”的，不像代码可以简单地覆盖。
| 合并方式 | 命令 | 适用场景 | 数据库迁移注意事项 |
|---|---|---|---|
| 普通合并 | git merge feature-branch |
功能开发完成，合并到 main | 确保迁移脚本的版本号（如 V2、V3）不冲突 |
| 变基 | git rebase main |
保持提交历史线性，避免分叉 | 变基会重写历史，如果迁移脚本已被其他人依赖，禁止变基 |
| 压缩合并 | git merge --squash |
将多个小提交合并为一个整洁的提交 | 适合将多个调试性的迁移脚本压缩成一个正式版本 |
# 将 feature/user-profile 分支合并到 main
git checkout main
git merge feature/user-profile
# 如果发生冲突（例如两个分支都修改了 V2__create_orders.sql）
# 手动解决冲突后：
git add V2__create_orders.sql
git commit -m "merge: 解决 V2 迁移脚本冲突，保留 email 和 phone 字段"2.5 标签（Tag）—— 里程碑的锚点
标签用于标记特定的提交，通常用于版本发布。在数据库迁移中，标签对应着数据库的“基线版本”或“发布版本”。
# 创建轻量标签（仅指向提交）
git tag v1.0.0
# 创建附注标签（包含作者、日期、签名信息）
git tag -a v2.0.0 -m "Release v2.0.0: 新增订单表和支付记录表"
# 推送标签到远程仓库
git push origin v2.0.0
# 查看所有标签
git tag --list
# 输出：
# v1.0.0
# v2.0.0
标签命名规范（数据库迁移推荐）：
- 语义化版本：
v主版本.次版本.修订号，例如v2.1.0。 - 主版本： 不兼容的数据库结构变更（如删除表、重命名列）。
- 次版本： 向后兼容的新增（如新增表、新增可空列）。
- 修订号： 补丁或回滚（如修复迁移脚本中的索引名称错误）。
2.6 核心概念关系总结
下表总结了五个核心概念在数据库迁移版本控制中的角色和相互作用：
| 概念 | 数据库迁移中的角色 | 关键操作 | 常见误区 |
|---|---|---|---|
| 仓库 | 存储所有迁移脚本和回滚脚本的完整历史 | git init, git clone |
将多个数据库项目混入同一个仓库 |
| 提交 | 记录一次原子性的数据库变更 | git commit |
提交信息模糊（如“fix bug”） |
| 分支 | 隔离不同特性的迁移开发 | git branch, git checkout |
长期分支导致合并冲突剧增 |
| 合并 | 整合不同开发线的迁移脚本 | git merge, git rebase |
忽略迁移脚本版本号冲突 |
| 标签 | 标记数据库的发布基线版本 | git tag |
忘记打标签，导致无法快速回滚到特定版本 |