尝试理解它为何有效。
前置要求：分支创建：Main -> 新发布分支 (release/2024-12-12) -> 新功能分支 (feature/NewMenu)
我将更改添加到功能/新菜单中。从 feature/NewMenu ->development 提出 PR，我被要求解决合并冲突，因为其他开发人员会将他们的功能分支合并到开发分支。
我在 git 控制台中按照以下步骤操作：
git 分支 o/p 显示：feature/NewMenu
git拉
git checkout 开发
git拉
git merge feature/NewMenu o/p：显示我解决的自动合并冲突 冲突。
git checkout -b mergefix/已解决
git 添加和提交
git 推送
当PR从mergefix/Resolved合并到develop时。其他有冲突的 PR 未标记为远程合并。
如果我修改最后 3 个步骤，它会按预期工作：
为什么这有效？有什么区别？
以下是来自BitBucket社区的回复：
在最初的步骤中，您在解决冲突后创建一个新分支 mergefix/Resolved，然后仅将更改提交到这个新分支。
当您创建新分支时，Git 使用当前的 HEAD 作为该分支的基础。因此，当您创建 mergefix/Resolved 时，它是基于解决合并后的开发分支，并且您包含冲突解决方案的提交仅在此新分支上。
但是，由于冲突是在切换到新分支后解决并提交的，因此 Git 不会将原始合并视为已在开发分支上完成。它本质上将冲突解决视为与功能/NewMenu 的初始合并尝试不同的开发线。
另一方面，在修改后的序列中，您可以在创建新分支 mergefix/Resolved 之前解决冲突并在开发分支上提交更改。当您在开发分支上解决冲突后提交时，Git 会将合并记录为已在开发分支上完成。之后创建分支 mergefix/Resolved 适合推送和提出 PR，但它不会影响合并提交本身如何被感知。
修改后的步骤按预期工作，因为合并解析直接提交到开发分支上。这使得 Git 认识到从 feature/NewMenu 到开发的冲突已经解决。