Git Flow中如何实现开发与生产分支保留不同配置文件版本

完全可以实现，以下是两种经过大量项目验证的落地方式，你可以根据自己的项目维护习惯选择：

方案1：用Git原生skip-worktree标记（零改造适配你现有项目结构） #

这个方案不需要调整当前文件结构，就能让两个分支各自保留专属配置，且不会把本地配置改动误提交：

• 先切到develop开发分支，把配置文件里的数据库连接项改成开发环境地址，提交作为该分支的配置基准
• 执行命令标记该文件为跳过工作区检测：git update-index --skip-worktree <你的配置文件相对路径>
• 切到生产分支（Git Flow里一般是main/master或者独立的production分支），把配置文件里的数据库连接项改成生产环境地址，提交作为生产分支的配置基准
• 同样在生产分支执行上述skip-worktree标记命令

注意：标记是本地仓库生效的，不会同步到远端，团队成员各自在本地对应分支执行一次即可。如果后续需要修改配置文件里的通用项（非环境专属的数据库地址这类配置），先执行git update-index --no-skip-worktree <配置文件路径>取消标记，改完提交后再重新打上标记就行。

这个方案下，你在本地修改配置文件的数据库地址不会被Git识别为待提交变更，分支合并时Git也会以两个分支各自提交的基准配置为准，不会出现配置被覆盖的问题。

方案2：配置模板+本地忽略（长期维护更稳妥的工程化方案） #

如果不想依赖本地标记，想从规则上彻底避免环境配置误提交，可以用更规范的配置管理方式：

• 把当前存了数据库地址的正式配置文件加入.gitignore，从Git追踪列表中移除
• 在仓库里提交一份配置模板文件，比如config.example.yaml，模板里保留所有通用配置，把数据库地址这类环境专属值改成占位符
• 开发、生产环境各自在本地维护正式配置文件，分别填入对应环境的数据库连接参数，因为文件被.gitignore忽略，所有本地改动都不会被提交
• 可以补个简单的初始化脚本，新环境拉取代码后自动把模板复制为正式配置文件，降低新人上手成本

这个方案完全规避了分支合并时的配置冲突问题，也不需要额外记标记命令，是中大型项目的常用做法。

避坑说明 #

不要直接把已被Git追踪的配置文件加到.gitignore里实现忽略——Git不会对已纳入追踪的文件生效.gitignore规则，后续分支合并还是会带出配置差异、产生冲突。也不要用assume-unchanged标记，这个标记是Git给大文件做性能优化用的，上游分支配置有变更时会直接覆盖你本地的修改，稳定性远不如skip-worktree。

内容的提问来源于stack exchange，提问作者fabraham