Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Why failed to merge branch if PR is approved

Deleted user September 22, 2020

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.

image2019-9-6_11-11-32.png

1 answer

0 votes
Julius Davies [bit-booster.com]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 23, 2020

 

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".  

 

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events