Alternatives to forking into the same account

People often ask the Support Team if one GitHub account can own two repositories in the same network. (A network consists of a root repository, its forks, forks of its forks, and so on.) Sometimes, people want to fork the same repository to their user account twice, so they can maintain two diverging projects. Other times, they want to fork an organization’s repository to that same organization.

It’s not currently possible for one account to own multiple repositories in the same network, but here are some alternative workflows that will accomplish the same goals.

Using GitHub Flow

We recommend using GitHub Flow in most situations. GitHub Flow involves each contributor adding commits to topic branches and then using pull requests to merge those changes into the default branch, usually master. In many ways, each branch is like a fork owned by the same account! For more information, see “Understanding the GitHub Flow.”

This approach does involve giving contributors Write permissions to your repository. If you’re concerned about contributors making irrevocable changes to important branches like master, you can protect those branches. For more information, see “About protected branches.”

Forking into a different account

If you’d rather use two separate repositories, another option is to create a fork in a different user or organization account. This is a great approach when you want someone to contribute to your project without having Write permissions to the original repository. That person can fork the repository to their user account, add commits to their fork, and then open a pull request to merge their changes upstream. For more information, see “Creating a pull request from a fork.”

Just remember that private forks have special rules. Private forks inherit the permissions structure of the parent repository and will be automatically deleted if the owner loses access to the parent repository. For more information, see “About forks” and “Deleting a repository.”

Duplicating the repository

If the new repository absolutely must be owned by the same account, you can duplicate the repository. This creates a new repository that starts out identical to the original repository but is not a fork. For more information, see “Duplicating a repository.”

Because the new repository is not a fork, you won’t be able to create pull requests between the two repositories. However, you can still push and pull changes between the two repositories by adding the original repository as remote for the new repository. For more information, see “Adding a remote.”

Need help?

Have questions about any of these options? Ask the Support Team! We’d be glad to help.


This feels like a simple, missing feature, despite the workarounds. If you can still pull and push, you should allow PRs.


This really feels like an unnecessary restriction, it should be easy, to add a name for a fork, to avoid naming conflicts in the same organization/user.

Consider following use-case, which our company currently uses:

We have a monorepo, containing a framework, and would like to create forks from it for derived projects.
Often new features are added in some of the projects, which should be merged to upstream again.
PRs would be the optimum for this.

Currently it is necessary to duplicate the repo, create a copy of the project branch on upstream and then create a PR directly in upstream.


I don’t understand the reason for this restriction to be able to fork a project only once into one account.
For example I use a fork of as a master for a blog / website.
But now I wan’t to create a second blog / website based on the same source repository. And of course I want to be able to merge future changes from the original into 2 different forks. But I have no idea how this should be done.

To create a second login only to be able to create a second fork is not really a solution.

To work inside the one forked repository with different branches for different websites could be a solution, but I am not sure, if this is the best way.

The most transparent way would be to have two different forks from the same source.

because the purposes of forks generally don’t really fit these use cases , a fork in the same account can be achieved but you need to contact GitHub Support to complete the fork connection

Except when dealing with CI/CD pipelines which are frequently pointing to a single organization.
Splitting a POC into a forked repo that can still deploy using the same pipeline is very useful.

1 Like