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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Difference of refs/pull-requests/<ID>/merge and refs/pull-requests/<ID>/from

When a pull request created, I saw following remote branch created automatically,

  • refs/pull-requests/<ID>/merge
  • refs/pull-requests/<ID>/from

What is the difference of these two?


BTW, I am trying to polling git to check new pull requests and automatically test them (I have no permission to change to Bitbucket server's setting to add a pull request notification plugin).

2 answers

1 accepted

5 votes
Answer accepted
Isabella Stephens
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Apr 17, 2018


First I want to point out that this is an internal implementation detail, and not part of our API. Anything you build that depends on these files may stop working after an upgrade to Bitbucket Server without warning. A better alternative may be to talk to your System Administrator about installing a plugin.

To answer your question, the "from" ref points to the head of the source branch of the PR. The "merge" ref points to a merge commit between the "from" ref and the head of the target branch. To understand why we track these it might help to read this blog post.

You should note that these refs are not automatically updated when a change is made to the branch. A user must view the PR in their browser for the refs to be updated. You can read this answer to understand why. You cannot rely on these refs being updated in order to pick up changes to the pull request as they happen.

Another option may be to look at our REST API - you can use this endpoint to retrieve all pull requests in a repository. From there, fromRef.latestCommit for each PR in the response will tell you the commit at the head of the source branch, similar to the "from" ref, except the value from the REST API will update automatically. 

Hopefully this helps clarify things.


Isabella - Atlassian

Thank you very much! It is very helpful.

Deleted user Jan 15, 2019


If "pull-request/*/merge" is an internal API that might break at any time, what would be the proper supported way to implement the solution suggested here in order to test the merged code instead of the source branch during PR builds?

Like # people like this

You suggest using a plugin, but every plugin I've found for BitBucket and Jenkins integration just uses the internal API, not the REST API. They all broke on me just now, so I'm scrambling to figure out how to get pull requests built automatically.

Like # people like this

For anyone landing here, I have not figured it out yet. We're just not building the merged PR, which is far less than ideal.

Like # people like this

I, probably like you @Todd Boyd have been hunting for a very long time to understand how to build Peer Review head in TeamCity from BitBucket Server. The TeamCity plugin just doesn't work, which means I have no way of integrating this to include pull-request analysis in SonarQube either.

My suggestion and next course of action is to create a micro web server in .net using nancy or embedio to enable us to integrate easily weith anything we like - and control our own destiny.

Like they "promised", they stopped generating the below reference BitBucket Server 7.0 onwards (because they switched to 2-way diff from 3-way diff.




So, when our organization upgraded BitBucket Server to 7.6 from 6.x all pull request builds (on merge) started failing. We had to then create merge reference ourselves before building.

Like falloutphil likes this

Same thing just happened at my organization.  Upgraded to 7.17 this weekend, and had to roll back again as this breaks how we test merges in our CI/CD pipeline.

It's an very useful feature to have and it's a it of a problem if it's not coming back.  Certainly testing just the head of the feature branch isn't adequate, and I'm yet to see an out-the-box alternative to merge refs suggested by Atlassian?

I am also interested in an out-of-the-box solution.

Bamboo can be configured to trigger a build when changes are committed. And BitBucket auto-updates a pull request when commits are pushed to the branch with an open pull request.

It shouldn't be too difficult to combine these into a solution to "auto-update the merge commit when commits are pushed to the branch with an open pull request" and "trigger a build when the merge commit of an open pull request is updated" .

We have been using the Stash Pull Request Builder plugin in Jenkins, which provides variables to build a URL for the destination repository and the source of the pull request which are configured as two separate repository references. We then do a local merge from the source into the destination during the PR build.

Way more complicated than it used to be, but it does work. YMMV on other build services.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events