关于采用Cherry-pick的Git分支策略的技术咨询

刚加入一支过去一年内完成从TFS到Git迁移的团队，跟大伙唠唠我们现在落地的分支策略，流程清晰还能保障生产环境的稳定性：

我们团队固定维护三个长期分支：

• Dev：日常开发的主力分支，所有新功能、迭代开发都在这儿进行
• Release：预发布准备分支，用来做发布前的最终验证和构建部署
• Master：生产环境的镜像分支，代码完全和已上线的生产环境保持一致

当Dev分支的迭代内容开发完成、测试通过后，按以下步骤推进：

1. 将Dev分支合并到Release分支（这里推荐用git merge --no-ff命令，保留完整的提交历史，方便后续追溯）
2. 基于Release分支执行构建，依次部署到测试、预生产等环境做最终验证
3. 当代码成功部署到首个生产环境后，把Release分支合并到Master分支，确保Master始终是生产环境的“精准快照”

遇到生产环境需要紧急修复的情况时，我们这么操作：

1. 先在Dev分支上完成修复代码的开发和测试（保证修复内容同步到开发主线，避免后续迭代丢失修复）
2. 通过git cherry-pick命令把修复的目标提交同步到Release分支
3. 基于更新后的Release分支构建部署到生产环境，验证修复生效
4. 确认修复没问题后，再用git cherry-pick把该修复提交同步到Master分支

• 严格禁止反向合并（比如从Release合并回Dev、从Master合并回Release/Dev），避免生产环境的代码污染开发主线
• 所有合并/cherry-pick操作都需要经过代码评审，确保代码质量和流程合规

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