不能只对存储过程“单独”做 Git 版本管理，必须将其作为数据库脚本的一部分导出为可读、可执行、可比对的 .sql 文件后纳入 Git 仓库；因其是数据库内部对象而非文件系统文件，Git 无法直接感知，否则会导致变更不可见、协作冲突、静默失配等问题。
直接回答：不能只对存储过程“单独”做 Git 版本管理，必须把它作为数据库脚本的一部分，和表结构、索引、函数一起导出为可读、可执行、可比对的 .sql 文件，再纳入 Git 仓库。否则 Git 看不见它，CI/CD 也跑不起来。
为什么不能直接 git add 存储过程对象本身
SQL Server（或 Oracle、PostgreSQL）里的存储过程是数据库内部对象，不是文件系统里的文件。你执行 CREATE PROCEDURE 后，它就存在 sys.procedures 里，Git 根本无法感知——就像你不能对内存里的变量执行 git add 一样。
常见错误现象包括：
- 开发在 SSMS 里改完
usp_GetOrderSummary，本地没导出脚本，直接提交代码，上线时发现生产库还是旧版本 - 多人协作时 A 改了参数，B 改了逻辑，没人知道谁覆盖了谁，因为没有文本形式的变更记录
- Git diff 显示“无变化”，但实际数据库行为已不同——这是最危险的静默失配
必须导出为 .sql 文件：选对工具和模式
核心原则：导出内容必须是纯文本、幂等、可重入、带完整依赖声明。推荐两种实操路径：
-
SSMS “生成脚本”向导：右键数据库 → 任务 → 生成脚本 → 勾选“特定对象”→ 选中目标存储过程 → 在“设置脚本选项”里务必打开：
Script DROP and CREATE、Include IF NOT EXISTS、Script USE DATABASE、Script extended properties -
C# + SMO 脚本工具（如知识库中提到的 SQLServer脚本导出导入.zip）：支持命令行批量导出全部存储过程到
Procs/usp_GetOrderSummary.sql目录结构，天然适配 CI 流程，且能自动处理依赖顺序（比如先导出用到的用户定义表类型）
避免使用 sqlcmd -Q "sp_helptext usp_GetOrderSummary" 这类方式：它只输出语句体，不带 CREATE 头、不处理权限、不兼容 Unicode 注释，且无法还原为可执行脚本。
Git 仓库结构怎么组织才利于维护
不要把所有脚本扔进一个 all.sql。按对象类型分层，让每次 git diff 能精准定位变更点：
/Schema/Tables/Orders.sql/Schema/Procs/usp_GetOrderSummary.sql/Schema/Functions/ufn_CalculateTax.sql-
/Data/Seed/InitialStatusCodes.sql（仅限静态码表数据） -
/Migrations/20260928_add_tax_rate_param_to_usp_GetOrderSummary.sql（带时间戳的增量变更）
关键细节：
- 每个
.sql文件顶部加注释：-- @depends_on: dbo.Orders, dbo.TaxRates，方便后续做血缘分析 - 禁止在脚本里写
GO以外的批处理分隔符；SQL Server 的GO不是 T-SQL 语句，是客户端指令，Git 不关心，但执行工具（如 sqlcmd）必须识别 - 所有路径、文件名用小写+下划线，避免 Windows/Linux 混合环境下的大小写敏感问题
自动化执行的关键：让脚本真正“可运行”
导出只是第一步。真正卡住落地的是“怎么确保每次拉代码后，能一键把本地数据库更新到最新状态”。这需要两个动作：
- 写一个
deploy.ps1（PowerShell）或deploy.sh（Linux），按目录层级顺序执行：Schema/Tables/→Schema/Procs/→Data/Seed/，每步失败立即退出 - 在 CI 流水线（如 Azure DevOps）中，用
sqlcmd -S localhost -d MyDB -i ./Schema/Procs/usp_GetOrderSummary.sql验证语法，并用SELECT OBJECT_DEFINITION(OBJECT_ID('usp_GetOrderSummary'))对比回显内容与文件是否一致
最容易被忽略的一点：存储过程里的 PRINT 或 RAISERROR 语句，在自动化执行时会变成干扰日志，导致解析失败。上线前务必清理或封装成条件编译块（如 IF @@TRANCOUNT = 0 PRINT 'Deployed'）。
