Bitbucket无法创建Release合并Develop的PR问题及解决咨询

为什么Bitbucket无法识别差异？ #

Bitbucket判断是否能创建Pull Request，核心依据是分支的提交历史关系，而非文件内容的实际差异。

你之前使用ours合并策略将release合并到develop时，Git会在develop的提交历史中添加一条合并记录，标记release的所有提交“已合并至develop”。Bitbucket读取这个历史后，就会认为develop已经包含release的所有提交，因此提示“develop已保持最新”。但实际上ours策略仅保留了develop的原有内容，完全丢弃了release的变更，导致文件内容仍存在大量差异，这就出现了历史标记与实际内容的矛盾。

如何将release分支的所有变更干净合并至develop？ #

根据develop分支在虚假合并后的状态，有以下几种可行方案：

方案一：撤销虚假合并（适合develop合并后无新提交的场景） #

1. 找到之前使用ours策略合并的提交记录：

   git log --oneline
   

   找到类似abc123 Merge branch 'release' into develop的提交行，记录该提交的父节点ID（可通过git show abc123查看，父节点会显示为parent字段）。

2. 重置develop到合并前的状态：

   git reset --hard <合并提交的父节点ID>
   

3. 强制推送更新远程develop分支（需提前告知团队成员同步，避免冲突）：

   git push origin develop --force
   

4. 此时重新在Bitbucket创建从release到develop的Pull Request，系统会正常识别到内容差异，完成合并时使用默认合并策略即可。

方案二：Cherry-pick release分支的变更（适合develop合并后有新提交的场景） #

如果develop在虚假合并后已经有新的提交，无法直接重置，可通过cherry-pick将release上的所有变更提交引入develop：

1. 确定虚假合并的时间点，列出release分支在该时间之后的所有提交ID：

   git log --oneline release --since="合并提交的时间"
   

2. 切换到develop分支：

   git checkout develop
   

3. 依次cherry-pick这些提交（若有冲突，解决后执行git cherry-pick --continue）：

   git cherry-pick <提交ID1> <提交ID2> ...
   

4. 推送本地develop到远程后，即可完成变更同步（无需再创建PR，因为变更已直接引入）。

方案三：Rebase develop到release分支（适合需要线性提交历史的场景） #

通过rebase将develop的提交重新基于release的最新版本，强制同步release的所有变更：

1. 切换到develop分支：

   git checkout develop
   

2. 执行rebase操作（解决冲突后执行git rebase --continue）：

   git rebase release
   

3. 强制推送更新远程develop分支（需提前和团队沟通）：

   git push origin develop --force
   

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