如何修复旧版本分支Bug并合并主分支时避免合并冲突

核心思路是不要做全分支合并，用cherry-pick精准同步修复提交，完全可以避免v2.0现有历史变更导致的大面积合并冲突，操作步骤如下：

• 先处理线上修复：切到本地v1.0分支，拉取远端生产环境对应的最新v1.0代码，保证本地工作区干净无零散改动，在这个基础上修复Bug。修复完成后正常提交、推送远端，走紧急发布流程部署上线，确认线上问题彻底解决。注意这次修复的提交要保持粒度最小，只放和Bug相关的改动，别夹带其他无关调整。
• 拿到修复提交的唯一标识：在v1.0分支用git log命令找到刚才那次修复对应的commit hash值，复制前7位就可以正常使用。
• 准备同步到v2.0分支：切到本地v2.0开发分支，拉取远端最新的v2.0代码，保证本地分支和测试服务器当前运行的v2.0版本完全一致，同样要清掉本地未提交的零散改动，避免干扰同步过程。
• 精准同步修复内容：执行git cherry-pick <刚才复制的修复commit hash>，把v1.0上的修复改动单独摘取到当前v2.0分支。如果Git提示冲突，不要强行覆盖v2.0的现有代码——毕竟对应功能在v2.0已经做了迭代修改，找负责v2.0该模块的开发，对照v1.0修复的问题逻辑，在v2.0现有代码结构上把对应的漏洞补上即可，核心是同步修复逻辑，不是硬搬v1.0的旧代码。
• 收尾验证：冲突解决完成（无冲突就等cherry-pick自动完成提交）后，把改动推送到远端v2.0分支，正常走测试流程验证即可。整个过程不会打乱v2.0现有的提交历史，也不会把v1.0和v2.0之间的版本差异代码乱合进来，不会出现大面积冲突的问题。

关键避坑：绝对不要在v1.0修复完成后直接把整个v1.0分支merge到v2.0，这种操作会把两个版本迭代之间的所有差异提交全部带入v2.0，不仅会产生海量冲突，甚至可能直接冲掉v2.0已经开发完成的新功能代码。

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