父分支feature_A合并至master后，合并feature_B的冲突规避与历史优化方案

分支创建阶段的基础规范 #

• 当需要创建依赖于未合并的feature_A的feature_B时，直接从feature_A分支切出feature_B，而不是从master切。这样能保证feature_B一开始就包含feature_A的所有修改，避免初始的基础差异。

feature_A合并到master后的同步操作（核心步骤） #

当feature_A合并入master后，必须及时将feature_B与最新的master对齐，不要等feature_B开发完再处理：

1. 拉取最新master：

   git checkout master
   git pull origin master
   

2. 同步master到feature_B，二选一即可：
   • Rebase（推荐，保持线性历史）：

     git checkout feature_B
     git rebase master
     

     过程中若出现冲突，解决当前冲突文件后执行git add .，再用git rebase --continue推进，直到rebase完成。这个操作会把feature_B的所有提交“重新应用”到最新的master之上，消除因master更新带来的基础差异。
   • Merge（保留原始提交历史）：

     git checkout feature_B
     git merge master
     

     解决冲突后提交合并记录，会保留feature_B的原始提交节点和合并记录。
3. 日常开发中定期同步：建议每天开始开发前，都执行一次上述同步操作，避免冲突积累到最后集中爆发。

PR提交前的收尾工作 #

• 再次同步最新master：提交PR前务必再做一次master到feature_B的同步，确保分支与远程master完全对齐，此时若有冲突，范围会更小，更容易解决。
• 清理提交历史：如果feature_B有大量零散的临时提交（比如“修复拼写错误”“调整样式”这类），用交互式rebase合并成有意义的提交：

  git rebase -i HEAD~3  # 数字3代表要修改最近3个提交
  

  在弹出的编辑界面中，将需要合并的提交前的pick改成squash或fixup，保存后完成合并，让PR的提交历史清晰易懂，方便code review。

日常习惯减少冲突 #

• 保持分支职责单一：每个feature分支只做一件事，不要在一个分支里堆砌多个无关需求，缩小冲突范围。
• 提前沟通协作：如果和其他同事在同一文件的同一区域开发，提前同步进度，避免重复修改导致冲突。

冲突处理的关键技巧 #

• 解决冲突时，不要盲目选择保留某一方的代码，结合业务逻辑判断，必要时找相关开发人员确认修改方向。
• 用git diff查看冲突前后的代码差异，git status确认所有冲突文件都已处理，确保没有遗漏后再提交。

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