Trying to understand why it works.
Pre-Req: Branch creation: Main -> New Release Branch (release/2024-12-12) – > New feature Branch (feature/NewMenu)
I add my changes to feature/NewMenu. Raise a PR from feature/NewMenu -> develop Where I’m asked to resolve the merge conflicts, since other developer would have merged their feature branch to develop branch.
I follow below steps in git console:
-
git branch o/p shows : feature/NewMenu
-
git pull
-
git checkout develop
-
git pull
-
git merge feature/NewMenu o/p: shows auto-merge conflicts I resolve
the conflicts. -
git checkout -b mergefix/Resolved
-
git add & commit
-
git push
When PR is merged from mergefix/Resolved to develop. The other conflicted PR is not marked as remotely merged.
If I modify the last 3 steps it works as expected:
- git add & commit
- git checkout -b mergefix/Resolved.
- git push
Why does this work? What is the difference ?
4
Below is the answer is received from BitBucket community:
- Original steps
In the original steps you are creating a new branch mergefix/Resolved after resolving conflicts and then committing your changes only to this new branch.
When you create a new branch, Git uses the current HEAD as the base for that branch. Hence, when you create mergefix/Resolved, it is based on the develop branch after resolving the merge, and your commit containing conflict resolutions is only on this new branch.
However, because the conflicts were resolved and committed after switching to a new branch, Git does not recognize the original merge as having been completed on the develop branch. It essentially sees the conflict resolution as a separate line of development from the initial merge attempt from feature/NewMenu.
- Modified steps
On the other hand, in the modified sequence, you resolve conflicts and commit the changes while still on the develop branch before creating the new branch mergefix/Resolved. When you commit after resolving conflicts on the develop branch, Git records the merge as having been completed on develop. Creating the branch mergefix/Resolved afterward is suitable for pushing and raising a PR, but it does not affect how the merge commit itself is perceived.
The modified steps work as expected because the merge resolution is committed directly on the develop branch. This allows Git to recognize that the conflict from feature/NewMenu to develop has been resolved.