-
Bug
-
Resolution: Fixed
-
Medium
-
3.3.1
The instructions to resolve a conflicted pull request are wrong, and recommend merging the target branch into the source branch. This is backwards, and would result in an unintentional merge if followed. I have to tell our devs to ignore these instructions.
A case study:
I create a pull request from release/1.0 -> feature/develop/1.1 to pick up bugfixes that have been committed to the release branch only. When conflicts arise, I am still seeing instructions like this:
This pull request has conflicts. You must resolve the conflicts before you can merge:
Step 1: Fetch the changes (saving the target branch as FETCH_HEAD).git fetch origin feature/develop/1.1Step 2: Checkout the source branch and merge in the changes from the target branch. Resolve conflicts.
git checkout release/1.0 git merge FETCH_HEADStep 3: After the merge conflicts are resolved, stage the changes accordingly, commit the changes and push.
git commit git push origin HEADStep 4: Merge the updated pull request.
These instructions suggest a merge from feature/develop/1.1 -> release/1.0 which is definitely not the behavior I want. I am trying to bring back bugfixes, not bring my 1.1 code into the 1.0 release branch.
Also see STASH-3083
- causes
-
BSERV-7052 "User not permitted message" when viewing a pull request
-
- Closed
-
- is duplicated by
-
BSERV-6918 The guidance for resolving automatic merge conflicts is destructive
-
- Closed
-
- relates to
-
BSERV-5228 Merge conflict instructions are incorrect when cascading merge fails
-
- Closed
-