Why failed to merge branch if PR is approved

unknown

We have multi environment project and each environment has own branch for CI/CD

e.g master, env/UAT, feature 1

when we create feature 1 we branch from master, when feature is finished we want to deploy it to uat.

To prevent developers pushing to uat directly we have restriction that says prevent pushes without pull request.

now when developer finishes feature he create PR from his branch to UAT. But if there is conflict he need to resolve it.

NOTE he cannot pull UAT into feature, because on UAT we have multiple features and if we decided to push only one feature from current sprint into release we dont want all others appear there.

So basically we have approved PR, but we cannot merge it from bitbucket website. So we go to repository and merge to local. But when we try to push merged changes system prevents to do this, because it is not from PR.

 

IMO if there is approved PR, developer should be able to push his merged commit, even with config "prevent changes without PR"

 

How can we act in this scenario?

Here is our flow.

Julius Davies _GitBoost_com_

 

If I understand correctly, the problem is that there's no way to merge a dirty merge through the bitbucket UI.  The only way to get a dirty merge accepted (where the merge required some conflict resolution) is via direct git-push.  And, yes, you are correct, there is no way around that. 

The trick is to engineer your situation to avoid the merge-conflict.  The tool for that is "git rebase".

Try rebasing feature-1 (against release-v1) and then try to merge it.   If that still doesn't work, wait until "release-v1" or "master" have received the other feature (feature-2?) that's making the merge dirty, then rebase, then try again.  

(Might help to squash feature-1 into a single commit before rebasing, but of course squashing will make no difference to the merge-conflict).

During the rebase if you encounter the same conflict then you know you're good!  

I think merging it into UAT with a conflict resolution (a dirty merge) is a bad idea since that means "feature-1" on UAT will be a little be different than "feature-1" in other environments.  The conflict resolution makes it a little bit different - basically the conflict resolution mixes a little of the other features already on UAT into "feature-1".