合并release分支到master分支时的冲突解决策略

咱们先来搞定这个冲突本身，再聊冲突解决时机的合理性——这其实是Git Flow工作流里非常典型的版本号冲突场景，处理起来逻辑很清晰：

一、解决这个版本号冲突的最佳策略 #

这个冲突的核心是master分支保留的是旧稳定版本号（0.11.0），而release分支已经更新到了待发布的新版本号（0.12.0）。按照Git Flow的设计，release分支就是用来准备正式发布的分支，所以新版本号才是我们需要最终保留的内容。具体操作步骤如下：

1. 先确保本地分支同步到远程最新状态：

   # 切换到master分支并拉取最新代码
   git checkout master
   git pull origin master
   
   # 切换到你的release分支（假设分支名是release/0.12.0）并拉取最新代码
   git checkout release/0.12.0
   git pull origin release/0.12.0
   

2. 回到master分支执行合并操作：

   git checkout master
   git merge release/0.12.0
   

   此时Git会提示版本配置文件（比如package.json、pom.xml这类记录版本的文件）存在冲突。
3. 打开冲突文件，手动清理冲突标记并保留正确版本号：
   将文件里的冲突代码块：

   +<<<<<<< destination:0632e01db317e3a4278fe08d4792da16b44af267
    "version": "0.11.0",
   +=======
   + "version": "0.12.0",
   +>>>>>>> source:e3ef91821bb20497449edc85049daa9e3398d8bf
   

   修改为：

   "version": "0.12.0",
   

4. 提交冲突解决结果并推送到远程：

   git add <你的版本配置文件名>
   git commit -m "Merge release/0.12.0 into master: resolve version number conflict"
   git push origin master
   

5. 别忘了Git Flow的收尾步骤：合并完master后，要把release分支也合并回develop分支（同样可能遇到版本号冲突，处理逻辑一致，保留0.12.0即可），之后就可以删除本地和远程的release分支了。

二、合并Release到Develop/Master时解决冲突是否合理？ #

完全合理，甚至是Git Flow工作流中预期的常规操作。

原因很简单：release分支的核心作用就是为正式发布做准备——其中必然会包含版本号更新、发布前的bug修复等变更，而这些变更很可能和master（保留上一个稳定版本）、develop（日常开发分支）的代码产生冲突。尤其是版本号这种在release分支里一定会修改的内容，冲突几乎是必然会出现的。

只要我们明确冲突的原因（比如这里是版本号的新旧差异），按照Git Flow的设计逻辑选择正确的代码版本，解决冲突就是合规且必要的步骤。

内容的提问来源于stack exchange，提问作者alex.mironov