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?
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?
@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?
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: https://marketplace.atlassian.com/plugins/ch.mibex.stash.templates/server/overview
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.
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.
Hey Community! We’re willing to wager that quite a few of you not only use Bitbucket, but administer it too. Our team is excited to share that we’ll be releasing improvements throughout this month of...
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