Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Why failed to merge branch if PR is approved

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

 

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
Community showcase
Published in Bitbucket

Powering DevOps with Bitbucket Server & Data Center

Hi everyone, The Cloud team recently announced 12 new DevOps features that help developers ship better code, faster   ! While we’re all excited about the new improvements to Bitbucket ...

1,804 views 0 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you