Git合并请求待审核场景下新工单开发分支创建策略咨询

这个场景的核心判断标准是第二个工单的开发是否依赖第一个工单的代码改动，通用处理规则如下：

场景1：第二个工单不依赖ticket-1-branch的改动 #

直接从最新的main分支拉取新的开发分支即可。

• 优势：完全不受第一个工单的审核修改、回退、合并不通过等风险影响，分支干净，后续合并到main的冲突概率最低。
• 注意点：拉取前先执行git pull origin main确保本地main分支是远程最新版本，避免基于旧版本main拉分支产生不必要的冲突。

场景2：第二个工单必须依赖ticket-1-branch的改动才能开发 #

此时只能基于ticket-1-branch拉取新分支，同时要做好风险规避操作：

• 第一个工单的MR审核过程中如果有代码修改，及时将ticket-1-branch的最新改动同步到第二个工单的开发分支：

  # 切换到第二个工单的分支，示例为ticket-2-branch
  git checkout ticket-2-branch
  # 拉取ticket-1-branch的最新改动
  git pull origin ticket-1-branch
  

• 第一个工单合并到main之后，立刻将第二个工单的分支变基到最新的main分支，清理分支提交历史，避免后续合并冲突：

  git checkout ticket-2-branch
  git pull origin main
  git rebase origin/main
  

• 如果第一个工单最终被驳回不予合并，直接将第二个工单的分支变基到main，手动移除依赖第一个工单的代码即可，相比直接合并回滚的操作成本更低。

禁止操作 #

不要为了图省事直接将未合并的ticket-1-branch的代码cherry-pick到新分支，后续两个分支的改动会完全脱节，合并时会产生大量难以排查的冲突。

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