Git选择性合并与部署流程技术咨询

嘿，你这套多团队并行开发的Git分支部署流程逻辑本身是挺合理的，但运行中出问题大概率是在分支合并细节把控或者环境部署一致性上踩了坑。我结合你描述的流程（三个团队并行开发特性→合并到test分支部署TQA→通过测试的特性合并到Staging→按需合并Staging到Master部署LIVE），整理了几个高频问题的解决思路，应该能帮到你：

一、特性分支合并到test分支的冲突与测试污染问题 #

• 坑点1：并行开发的特性合并到test后互相干扰，导致TQA测试结果不准
  解决思路：

  1. 强制要求每个团队在合并到test前，先把test分支的最新代码拉到自己的特性分支，本地解决冲突并验证功能正常：

     git checkout feature-teamA
     git merge test
     # 手动解决冲突后提交，再推送到远程仓库
     git push origin feature-teamA
     

  2. 给test分支加个保护规则：必须通过PR（Pull Request）+ CI校验（比如单元测试、代码规范检查）才能合并，直接push会被拒绝，避免不合格代码混进测试环境。

• 坑点2：某个特性测试不通过，但已经合并到test，污染了测试环境
  解决思路：
  不用慌，用git revert撤销该特性的合并提交就行，这样test分支能快速回到干净状态，不影响其他特性的测试：

  # 先找到该特性合并到test的提交ID，用--oneline看精简日志更方便
  git log --oneline
  git revert <目标提交ID>
  git push origin test
  

  等这个特性修复完成后，再重新合并到test分支就行。

二、从test合并到Staging的精准性问题 #

• 核心疑问：怎么确保只有通过TQA测试的特性代码被合并到Staging，不会带进来未通过的代码？
  解决思路：
  别直接把整个test分支merge到Staging，改用cherry-pick的方式，只挑选通过测试的特性对应的合并提交：

  git checkout staging
  # 找到通过测试的特性在test分支上的提交ID
  git cherry-pick <通过测试的特性提交ID>
  git push origin staging
  

  另外给Staging分支设个权限，只有测试负责人或者发布管理员才能操作合并，避免开发同学误把未通过的代码合进来。

三、Staging合并到Master及LIVE部署的稳定性问题 #

• 坑点1：Staging合并到Master时突然出现冲突，导致发布中断
  解决思路：
  发布前提前做预合并验证！在本地拉取最新的Staging和Master分支，先模拟合并解决冲突，确认没问题再推到远程执行正式合并：

  git checkout master
  git pull origin master
  git merge staging --no-commit --no-ff
  # 检查并解决冲突，确认代码正常后再提交
  git commit -m "Merge staging to master for LIVE release"
  git push origin master
  

• 坑点2：Master部署到LIVE后出问题，需要快速回滚
  解决思路：
  1. 用标签（Tag）管理每个发布版本，每次从Master部署到LIVE前，给当前Master的提交打个带版本号的标签：

     git tag -a v1.0.0 -m "Release v1.0.0 to LIVE environment"
     git push origin v1.0.0
     

  2. 如果发布后出问题，直接切到上一个稳定标签的版本部署就行，同时用git revert撤销Master上的错误合并提交，保证分支干净：

     git checkout v0.9.9
     # 执行你的LIVE部署命令
     

四、流程规范落地的小建议 #

• 给各分支设置清晰的权限：比如开发分支只有对应团队能推送，test分支必须PR+CI校验才能合并，Staging和Master只有特定人员能操作。
• 用CI/CD工具自动化部署：比如合并到test后自动部署TQA，合并到Staging后自动部署预发布环境，打标签后自动部署LIVE，减少人工操作的失误。
• 定期清理废弃分支：比如特性合并到Staging后，对应的特性分支可以删掉，避免分支堆得太多导致管理混乱。

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