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

When creating a Pull Request in a Fork repository the default target branch is from the original repository

When creating a Pull Request in a Fork repository the default target branch is from the original repository.


I have a repository "main-repo" with "master" and "feature1" branches.

I forked this repository into "repo-fork-1".

If I go to the "feature1" branch in the "repo-fork-1" and enter in the "compare" view, it shows the diff between this branch (as source) and the "master" branch in original repository "main-repo" (as target). If I press then "Create Pull Request", the Pull Request is created in the target repository.

Even I can change this before creating the Pull Request, one can easily create the Pull Request for the wrong target branch (i.e., the same branch name but in the wrong repository), since it's not expected that it will choose the original repository as default. In my opinion this is wrong.

Is there already an issue opened for this?

6 answers

Our team has run into this problem twice within the last few days. We would love for control over this.

Yep, my team too.  Someone will make a mistake at some point.

I just experienced this myself and was confused as to how my PR was created in the original repo, thinking I had somehow misconfigured the fork.. 

Same here. Easy to commit mistakes. My company uses forks as a means to start new projects from template projects. This behavior is generating a lot of confusion when creating PRs.

Like Vitalii Saienko likes this

Same problem here, I would like to fork from a template repository, but then pull requests are made to the template repository by default.

Like Edgard Zavarezzi likes this

Our team mistakenly forked several of our template repos not knowing that this workflow would create such chaos.  While this behavior might be "by design", it would be very helpful to many of us if there were some text present during the process of creating a fork that points out how the resulting repository is supposed to be used.  

On that note, is there any way to reconfigure these existing repos to work like normal repos?  Or do I have to delete the repos and re-push the code?  Will it retain my commit history when I do this?

  1. Rename the old repo to like 'myrepo_forked'
  2. Create a new repo with the original name 'myrepo'
  3. During the create wizard there's an import option, use the 'myrepo_forked' as the source of the import
  4. There's a screwy permissions box; it's your bitbucket creds; somehow it can't use your current session. A colleague's Chrome autofilled the username with his full name from like a shipping autofill instead of the saved bitbucket creds so be careful on that one
  5. After the import is complete, you can eventually delete 'myrepo_forked'
Like # people like this

@Roger Barnes my team is experiencing the same problem - our use case is that we have a template / scaffolding project that gets forked whenever a new project is created to save on a lot of boilerplate in initial development. Now any PRs created on the forked projects default to targeting the template project, which is not what we want. Is there any way to change this behaviour in an existing project?

The same thing. We have a template and creating forks for new projects. Any updates on that, guys?

Like Stefan Stupar likes this
Roger Barnes Atlassian Team Oct 30, 2017

Forks are designed for a specific purpose and not intended for seeding new, unrelated repositories. As such, they don't and won't work that way by default.

Project level settings are now available in Bitbucket Server (from 5.2) so you can create a regular repository within a project that inherits settings.

If it is repository content that you wish to use as a template, I suggest cloning and pushing the contents to a regular repository, or using an add-on such as:

When can we create pull requests with _NOT_ forks?

Has this been fixed? Can we control this at all?

You're right. I was creating Pull Requests on a Fork repository because I was doing tests. In a real scenario this should not be a problem. Thanks for the explanation.

0 votes
Roger Barnes Atlassian Team Oct 25, 2015

Hi Silvestre, Forks are commonly used as a means for contributing changes back to the upstream repository, hence the default of referring back to it. Under what circumstances do you have multiple people collaborating on a single fork where changes end up in the same repository? It seems an unusual situation, or perhaps an unusual use of pull requests.

It may be common but only in your standard open-source workflows. Yet forks are not always used to contribute changes back to upstream within companies.

A lot of companies are using a centralized organization owned repo where people are working on at the same time.

PR are generated via branches created directly on the centralized repo, not forks.

Forks are on the other hand only created for the sole purpose of having a copy of a repository that has to diverge in a different way and should for all purposes be regarded as its own project. They should not even be aware that there is upstream. And changes to these forks should never become part of the parent.

In my use-case, I forked a repo exactly for that reason and was highly confused that the PR target would point to the parent of the fork; esp. since I forked it to the organization namespace. (I would expect the PR to upstream behavior if I created my own fork in my own namespace.)

I am afraid, that in the future some changes intended for the fork will end up in the parent and create chaos there. Currently, I have to always change the target branch in a PR to the fork itself.

My main concern is not the default, but that I am apparently unable to change it. It would be great to be able to change it via a config to where PR should be pointed.

Like # people like this

@Roger Barnes 

Our use case pretty much aligns with what @k0pernikus  mentioned here

Like mattias_andersson_2 likes this

We have also the use case mentioned by @k0pernikus. Each fork represents its own distinct project that inherits from upstream, with minimal (if any) contributions back to the upstream repository. In this situation it makes sense to make the default PR target the forked repository.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Bitbucket

⭐ Calling all Bitbucket and DevOps experts: Special showcase opportunity ⭐

Hi, Bitbucket community! Are you a DevOps practitioner (or know one in your network)? Do you have DevOps tips, tricks, or learnings you'd like to share with the community? If so, we'd love to hea...

1,477 views 4 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