I had three open pull requests open, all to 'development'. Two were a PR by another user and one was my own.
My local copy of development was behind, so I pushed it to the remote. The act of pushing from development local to my development remote to unexpectedly caused two of the open PRs to merge automatically into development.
This was very much not wanted because there are outstanding problems to fix in those PRs. And one of the PRs was set to require approval which it had not been given.
What might have caused this? Are there criteria for automatic merging?
Thanks for reaching out.
A pull request can be merged automatically if its source branch is directly or indirectly merged into the target branch externally, i.e. if the source branch tip commit becomes reachable from the tip of the target branch.
Here's a simple example:
/ . .
/ . .
Letters are commits, and let's say there're three branches here:
Now, if pull request F → master is merged first, pull request E → master will be merged automatically because all commits from b1 are now reachable from master, i.e. there's no difference between b1 and master anymore.
Similar thing will happen if someone creates a merge commit with same consequences locally and then pushes it up to Bitbucket – all affected pull requests will be automatically merged.
Does this make sense?
Let me know if you have any questions.
@ade, are you sure that your local copy of development was behind? If so, you would have wanted to pull from the remote, rather than push because if it was behind, that means the server had commits that you did not.
It's a bit hard to tell what the exact state of everything was when you pushed, so the below is a little on the general side, but most of it should be applicable.
That the pull requests were merged implies that your local copy of development contained the commits that were on the source branches of those pull requests. The reason this circumvents the pull request merge checks is because those merge checks are run when a pull request is merge is started (which is stopped if any of the merge checks veto the merge), however a push to a branch will not trigger those checks.
To improve this workflow and avoid changes being pushed to your development branch outside of the pull request workflow, you can set up a Branch Permission (available in repository settings) to disallow changes to that branch except for pull requests. Then when a remote push is attempted it will be blocked.
Hope this helps.
John van der Loo
Developer, Bitbucket Server
This really sounds like your local development branch contains the commits of the pull requests that had not been merged until you pushed them to the remote.
Much like John has said setting up branch permissions to require a pull request will prevent users from manually pushing to the remote.
We have this setup up ourselves with an exception in place for our admin group in case of emergencies.
You might be interested to read more about branch permissions here: https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html
Thanks all, and yes – to clarify – I switched to a different development machine which had an already checked out copy of development which both was behind my "other" copy of development but git also was saying it was ahead. So I pulled then pushed.
I think yes, I must have previously pulled some commits from the branch (the source of the PR) into this local copy by accident (or forgetting that I had done that). And then carelessly pushed that rather than stopping to ask why it was ahead!
Anyway, yes thanks @Jimmy_Seddon I am familiar with branch permissions, they are excellent! In fact I had to turn off the limitation on "rewriting history" in order to fix the situation using a "RESET head" then a "push with force" option.
In this situation given it is the development branch I do allow myself as manager of the project to manually push to this branch, but not the rest of the team. Unfortunately with great power comes great responsibility etc *oops*
Our "master" is updatable by PR only (we use branch permissions for that).
Announced in this blog, this holiday season we’re celebrating all things CI/CD and between now and the end of 2019 we’ll be showcasing content, use cases, feature announcements and more. One featur...
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