Git分支策略（结合CI/CD）执行流程自查，求指正遗漏环节

一、流程中的错误点 #

• 步骤3的Git命令逻辑错误：
  按照流程设计，feature分支需基于development分支创建，正确的命令流程应为：

  # 先切换并拉取最新的development分支
  git checkout development
  git pull origin development
  # 创建并切换到本地feature分支
  git checkout -b feature/audio
  # 提交代码修改
  git add filename
  git commit -m "feat: 实现音频功能"
  # 首次推送远程需关联分支
  git push -u origin feature/audio
  

  原命令git checkout -b feature/audio origin/feature/audio是基于已存在的远程feature分支创建本地分支，和步骤2“从development创建feature分支”的逻辑矛盾，不符合流程设计。

• 步骤7的Git命令与提交信息错误：

  1. 命令层面：若要在已有的release/v1.0.1分支上做紧急修复，正确流程是拉取远程最新分支而非重复创建：

     git checkout release/v1.0.1
     git pull origin release/v1.0.1
     # 修复代码
     git add filename
     git commit -m "fix: 紧急修复音频功能bug"
     git push origin release/v1.0.1
     

     原命令git checkout -b release/v1.0.1 origin/release/v1.0.1会创建重复的本地分支，无实际意义。
  2. 提交信息层面：紧急修复的commit信息不应标注为"audio feature"，需明确是修复类提交，便于后续追溯问题。

• 步骤8的标签操作不完整：
  创建版本标签后未推送到远程仓库，正确操作需补充：

  git tag 1.0.1
  git push origin 1.0.1
  

  否则标签仅存在于本地，团队其他成员无法获取该版本标记。

二、流程中的遗漏环节 #

• 代码评审环节缺失：
  步骤4发起PR后，需增加团队代码评审环节，只有评审通过且无重大规范问题后，才能合并feature/audio到development分支，避免不合规代码进入集成分支。

• feature分支创建前的代码同步：
  步骤2创建feature分支前，需先拉取development分支的最新代码，确保feature分支基于最新集成代码创建，减少后续合并冲突概率。

• release分支的预发布验证：
  步骤7创建release/v1.0.1分支后，应先通过Azure Pipeline部署到预发布环境，进行生产前的最终验证（含性能、兼容性等），确认无误后再合并到master分支，避免直接合并后出现生产问题。

• 生产环境部署的审批机制：
  步骤9触发生产部署前，需添加手动审批环节（如在Azure Pipeline中配置审批人），必须经过QA、产品或运维团队确认后，才能执行生产部署，降低误发布风险。

• release分支修复后的同步逻辑：
  步骤7中，release分支的紧急修复合并到master后，必须同步合并回development分支，确保后续feature分支和下一个release版本能包含该修复，避免修复内容丢失。

• feature分支的清理：
  步骤4代码合并到development后，需及时删除本地和远程的feature/audio分支，避免分支冗余：

  # 删除本地分支
  git branch -d feature/audio
  # 删除远程分支
  git push origin --delete feature/audio
  

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