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!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Why does a bitbucket pipeline on one branch try to merge with a commit from another branch


We have a build that failed with the following log during the "Build Setup" step:
+ git reset --hard 38167b31fd00
HEAD is now at 38167b3 DAT-2701: fix some thing

+ git config bitbucket-pipelines
+ git config
+ git config push.default current
+ git config http.${BITBUCKET_GIT_HTTP_ORIGIN}.proxy http://localhost:29418/

+ git remote set-url origin
+ git merge 263e287ee12d --no-edit || exit $CONFLICT_EXIT_CODE
warning: Cannot merge binary files

38167b3 is the head of a feature branch.  263e287ee12d is a merge of that feature branch with our release branch.

So why does the pipeline setup for the feature branch merges in a commit that was made later?

4 answers

We enountered the same problem. Our expectation was that the Pull Request build executes on the branch the pull request is from, and we don't want the build to use anything from the destination branch.

@Graham GatusThanks for the tip on using "branches" pattern, but this requires us to enforce using patterns when we create branches (e.g. /feature/...).

Seems Bit Bucket doesn't have any other option in this case and Pull Request pipelines becomes useless.

1 vote
Graham Gatus
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Mar 06, 2019 • edited

@Rutger Claes do you mind sharing a snippet from your bitbucket-pipelines.yml file?

It sounds like you have defined a pull-requests section in your bitbucket-pipelines.yml file.

If a branch matches the pattern defined for pull-requests, when a pull request is created, the destination branch will be merged with the source branch, and a pipeline run against the result. This can be used run tests against the potential result of a merge.

If you don't want this behaviour, instead of defining a pull-requests section, use a regular branches section instead. e.g:

- step:
- echo "This script runs on all branches that don't have any specific pipeline assigned in 'branches'."
- step:
- echo "This script runs only on commit to branches with names that match the feature/* pattern."
- step:
- echo "This script runs only on commit to branches with names that match the feature/* pattern when a pull request is raised."


This costed us about a day of investigation. The Web UI clearly shows which git hash it builds from. The fact that an additional merge happens is hidden within the "Build Step".

From the pipelines web page it looks like the build with the same git commit passes, and at some point it breaks. We suspected some of our tests were unstable (non-deterministic) and it took considerable amount of time to figure out that the code that was tested does not come from the hash that is displayed in upper left corner of the Web UI.

Why does it do this? If I wanted to update my branch with respect to the destination branch, I would do that myself.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events