18

We've started using Bitbucket Server on our team, and want to enforce the use of pull requests to get commits from feature branches into our main integration branches. To enforce this, we turned on the branch permissions feature that prevents merges without a pull request for those branches. This works great, until we get a pull request that has a conflict.

In this case, the instructions say to manually fetch the head of the source branch and merge it to the target, then push this up. However, the merge commit gets rejected by the branch permissions!

Are we missing something here, or is it not possible to manually merge when using branch permissions?

3bh
  • 806
  • 1
  • 6
  • 12

3 Answers3

17

On BitBucket server, when we get any conflict while merging any pull request, we can use git bash tool to resolve it on our local system and then we can commit and push our changes to remote feature branch and merge it to main branch.

Following steps need to be followed in order in our local system’s git bash tool.

(1) Open git bash tool and checkout or switch to your local feature branch.

(2) Pull the latest changes from the main branch (say 'master') into feature branch.

git pull origin master

(3) If above command fails due to some local changes then use below command to stash them otherwise move to next step.

git stash

followed by -

git pull origin master

(4) In case of conflict, automatic merge will fail so we need to merge it manually. Use below command to resolve conflicts.

git mergetool

By default, it will display all the available merge tools and one of them will be picked automatically. If we feel we are much comfortable with any other tool then we can also configure that and git will open that tool for us for conflict resolution.

(5) Once the conflicts are resolved then commit the changes into feature branch.

git commit

(6) Push the changes to remote feature branch.

git push

Verify on BitBucket server, now pull request should get updated automatically.

Again try to merge it; in case of no conflict it will get merged successfully.

If it has merge conflict again (if someone has committed new changes in main branch during we were resolving conflict on our local system) then follow the above steps again to resolve them.

We should be able to successfully resolve any conflicts if we have followed the above steps in order.

Thanks, hope it helps.

Aavesh Yadav
  • 317
  • 2
  • 4
  • this looks promising for my issue. Should i use 'master' or should that be the name of the branch i'm trying to create a pull request into? Thanks! – v3nt Aug 22 '18 at 14:59
  • Sorry for being late. These are the standard steps to resolve conflict for any of the branches, we just have to put the specific target branch. In your case, you can take the branch you are trying to merge into. Thanks. – Aavesh Yadav Oct 18 '18 at 17:39
6

When we get into the dirty automatic merge scenario, whether by branch permissions or by automerge conflicts, using feature/bugfix branches, we do the following:

In your local clone of the repository:

  1. Checkout the destination branch with 'git checkout [destination branch]'.
  2. Update the master branch with the most recent changes from the remote with 'git pull origin [destination branch on remote]'.
  3. Checkout a new feature branch with 'git checkout -b feature/[my branch description]'
  4. Get the latest changes from the source branch with 'git fetch origin [source branch]'.
  5. Merge the fetched changes into the destination branch with 'git merge FETCH_HEAD'. We used 'git fetch' instead of 'git pull' to avoid checking out the source branch and updating it first. Thus the difference between 'git merge [source branch]' and 'git merge FETCH_HEAD' (after 'git fetch origin [source branch]') is that the latter will merge the state of that branch on the remote, while the former merges the local state of that branch (which may not be the same or might not even exist).
  6. Now fix the conflicts.
  7. Stage the changed files with 'git add' or 'git stage'.
  8. Commit the changes to the feature branch with 'git commit -m [your commit message]'.
  9. Push the changes to the remote with 'git push origin feature/[my branch description]'.
  10. Start a new pull request in Bitbucket with the URL provided in the response message. Make sure to select the correct destination branches. Auto-merging should be allowed to continue when possible.
  11. Decline the original pull request now that you have created the new one. Ensure no other commits were added to the original PR automatically in your absence.

Here it is on the CLI:

git checkout <destination branch>
git pull origin <destination branch on remote>
git checkout -b feature/<my branch description>
git fetch origin <source branch>
git merge FETCH_HEAD
<fix conflicts>
git stage <changed files>
git commit -m <my message>
git push origin feature/<my branch description>
<continue in bitbucket>
Dave Neeley
  • 3,526
  • 1
  • 24
  • 42
4

The instructions, unfortunately, come a bit unstuck with certain combinations of permssions, and it's something we hope to fix sometime (I work on Bitbucket).

To get around the issue you can resolve the conflicts on the source branch by merging changes in from the target branch.

Rog
  • 4,075
  • 2
  • 24
  • 35
  • 4
    Doesn't seem like it got fixed. I've seen elsewhere that the "generic instructions" presented work for most cases but it seems strange. If I'm working on changes and generated a merge conflict with the target branch, why would the typical use case be to update the target branch instead of the source? The whole point of the PR is to vet source changes to get them into target, not the other way round. – iheanyi Jan 21 '20 at 23:24