Git工作流中Pull Request应合并到main还是dev分支？

直接对应你的开发流程选就行：

• 刚写完的新功能、未经过演示环境验证的代码，提PR时目标分支选dev，合并后直接部署到你的演示环境做功能验证
• 等dev上的功能在演示环境跑通、没有逻辑问题、符合上线要求了，再从dev分支提PR到main，合并后部署到生产环境
  你之前了解到的「不应该直接向main分支推送代码」是对的，所有进入main的代码都必须走PR流程做卡点，不管是自己做检查还是团队做评审，本质就是避免未经验证的代码直接流到生产环境出故障。

这套方案完全可行，是个人项目、小型团队项目最常用的轻量分支管理方案，完美适配你现在两套环境独立对外的场景，只要配套几个简单的使用规则就不会乱：

• 禁止直接在main、dev两个长期分支上直接提交代码，所有新功能开发都从最新的dev分支拉取，新建feature/功能名格式的独立分支开发，开发完用git push origin feature/功能名推到远程后再提PR
• 功能分支提PR合入dev后，自动触发部署到演示环境，用来做新功能的测试、预览
• 固定发版节奏（比如每周一次、或者单个功能验证完就发），把dev上验证通过的代码提PR合入main，合并后触发生产环境部署
• 如果线上出紧急bug，直接从main分支拉hotfix/问题描述格式的分支修复，修复完先提PR合入main上线，上线完成后记得把main的修复代码同步合并回dev，避免后续dev分支发版时把之前的bug又带上线。

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