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

To be perfectly honest, that sounds like a bad idea right from the start. I know it’s precisely the advice given at that repo, but I think it’s bad advice. Your website repos shouldn’t be forks of the template project, that’s a loaded relationship that implies way too many things that aren’t really desirable. For starters, it ties your site to that project. What if, say, six months from now you decide to switch the site to a different backend?

You should only be working in a fork of an upstream project if you’re either (a) developing contributions that will be submitted back to the upstream in the form of PRs, or (b) furthering development of the project itself, but independent of the upstream development. (Either because it’s stalled, because you have different ideas for what direction it should take than the upstream developers do, etc.) A derived project isn’t a fork, and a repo shouldn’t be a fork if it’s being developed in ways that would never be applicable to the upstream, or even reusable in general. (Like, by creating content for a specific website.) A fork is meant to facilitate a two-way relationship, but it doesn’t sound like there’s any expectation (nor need, desire, or interest) for any of your changes to ever go back to the upstream.

And Github has actually created the perfect solution to this: Template repos. That’s how that Beautiful Jekyll repo should be configured, instead of telling people to fork it. If it were converted to (or offered a second repo configured as) a template repo, then projects looking to use that repo as a starting point for their own projects could create non-fork copies of the contents, which make a lot more sense.

Well, ideally, you create a new repo, and somehow incorporate the Beautiful Jekyll repo as a starting point. But you also keep it isolated, whether that means cloning it into a subdirectory of your new repo, or setting it up as a git submodule. The point is to have it there, but clearly separate from your own content.

If all you want is a one-way update mechanism (changes flow from the upstream to you, but not in the other direction), then you don’t need a fork of the repo, just a clone. Any clone can always pull new changes from the upstream.

That would actually be a workable option, using git worktree to manage each branch separately, but it would have all of the same problems as multiple forks, plus more. Like, say you wanted to hand off one of those sites to another maintainer, at some point. You can’t really transfer ownership of a branch.

Separate projects should be in separate repos. And projects that aren’t related to each other should be in independent repos, not forks. A fork is not the way to create a dependency, that’s just bad separation of concerns, and it’ll end up causing problems at some point.

That sounds like a nightmare, honestly, and you pointed out exactly why:

Merging in future changes from upstream sounds like a nice idea. But if you’re developing your own, separate content inside a fork of that upstream, you’re going to have to resolve merge conflicts unless you very strictly isolated your work to avoid making any alterations to the upstream sources. How extensive and how severe those conflicts will be is entirely dependent on how badly your changes trampled all over the original files from the upstream project.

Now, imagine you’ve created thirty different sites that same way, each one a separate fork off the upstream. You’d have to go through that same conflict resolution process thirty times, if you wanted to update all of the sites. I mean, on the plus side, I guess you’d know what you were going to be doing with the whole rest of your week. Still seems like a colossal waste of time and effort, though, vs. maintaining proper encapsulation to keep the upstream codebase separate from your own.

You can make at most one fork of a repo, because you should only need at most one fork of a repo — if even that many! Unless you’re effectively developing the upstream project itself (not a separate project that merely depends on it), the total number of forks required isn’t even one — it’s zero. Forking as a means of creating a dependency on an upstream is a terrible and completely unsustainable development model.


I wanted to fork a repository to work on some GitHub actions without polluting the main repository’s release history and job history. Is there a better way to do that? As I understand it, GitHub Actions execute from the main/master branch. I need to troubleshoot my changes without causing distractions from failed job alerts and whatnot.

It depends what you mean.

  1. If you want to make modifications to a project’s use of Github Actions, you should fork that project.
  2. If you want to make modifications to a Github Action itself, and the changes you’re making are intended to be contributed back to the parent project for the Action, then you should fork that Action’s repo.
  3. If you want to create a new Action, using another Action’s code as a starting point, then you should create a new project from a clone (not a fork) of that Action’s repo.

Again, depends what you mean.

If you’re making changes in a project’s .github/workflows/, and you make those changes in a branch, then if Actions are enabled in the upstream repo generally, and as long as it’s not a private repo, the workflows on your branch will be used for a PR submitted from that branch.

There are some restrictions on things like access to secrets, when running that way (so that you can’t submit a PR containing a workflow that uses: actions/steal-all-the-secrets@latest, for example, and have it execute in the upstream repo), but in general workflow changes can be tested from non-default branches and submitted via PR.

You can also enable Actions in your fork of the repo (it’s not enabled automatically), and test your changes there before submitting a PR to the upstream repo.

If, OTOH, you’re modifying or creating the code for an Action and want to test your changes, you can create a workflow that references a non-main version of an action’s code — any other branch, or even any specific commit, can be specified in the uses: line of a particular workflow. (See the documentation on Actions release management for details.)

So, writing a workflow in a myaction-testing repo that uses: ferdnyc/myaction@topic-branch or even uses: ferdnyc/myaction@${COMMIT_HASH} would be a way for me to test in-development changes to my myaction repo.

(You could test directly from the myaction repo itself, but that sounds potentially confusing to me. That being said, Referencing an action in the same repository where a workflow file uses the action is technically possible.)

Our use case is related to multiple template repositories that share code, folder structures, instructions, and so on but spawn different types of projects. We are currently using branches of the most basic template to specialize them, but you can’t create a new repo from any branch of a template other than the default branch, so each time a new repo is created we have to create the new repo with all branches included, then merge the desired branch type into the default branch before starting work. It’s a pain that would be solved by allowing renamed forks of the same repo within one org.


I found this great answer on SO that detailed a way to duplicate the repo to the same organization and keep them in sync, while one can be public and the other can be private

GitHub’s web interface just reminded me today of another reason forking is not the right approach for creating derivative projects:

The code tree and commit histories for forked repos are NOT searchable using the GitHub. You’re told to go search the parent repo. Witness :

(Repo-local Issues and Discussions are searchable, but not any of the code activity.) Forks really are intended only for code that’s being prepared for submission back to the parent codebase.

This also has implications for true forks of long-standing dead/abandoned projects, like the one I was attempting to search today, Freetz-ng.

Particularly if a fork becomes the “new official” repo, and the original repo is declared unsupported. (The of the Freetz repo actually says at the top, effectively, “This is dead, go use Freetz-ng.”)

In those situations, it’s advisable for the fork to detach itself from the orignal parent project, removing the “forked” relationship, so that it becomes a parent project in its own right. Until that’s done, its contents won’t be indexed and searchable, because it will still be considered just a development tree for the parent project.

For developers maintaining forks that aren’t really forks anymore, I’d say they owe it to themselves and to their users to eliminate that forked-from relationship and promote their repo to first-class status.

LOL. Oh wow, it’s even more complicated than that:

  • Code in forks is only searchable if the fork has more stars than the parent repository. Forks with fewer stars than the parent repository are not indexed for code search. To include forks with more stars than their parent in the search results, you will need to add fork:true or fork:only to your query. For more information, see “Searching in forks.”

That is just… bizarre.

it’s advisable for the fork to detach itself from the orignal parent project, removing the “forked” relationship

This “detach”/“remove forked” means

  • delete the repo, including Issues, Discussions, comments on commits, issue counter starts again at 1 and all old links are invalid etc
  • recreated the repo, reconfigure everything and upload an backup

a bad idea

Well… yes, which is why it’s better not to start with that relationship in place to begin with. But for a repo that’s been forked from another and is now finding that relationship to be detrimental (code not indexed/searchable, etc.) it’s really the only option.

The forked repo doesn’t have to be deleted, anyway. It can simply be deprecated/archived, and its contents moved over to a new, unforked repo with commit history intact. There are plenty of bot options for migrating open issues and other items from the former home to the new one, or links to the old repo issues can simply be published in a single starter issue at the new repo. It’s really no different, conceptually, from migrating old issues out of a Bugzilla or Mantis instance into GitHub Issues, something projects do all the time. Yes, there’s a period of disconnect/fracturing, but it’s not insurmountable and it’s only temporary.

There might even be a way to do some name-juggling and create the new repo at the old name, with the old forked version renamed to something else. I’ve never looked into that.

Worse than continuing to maintain a repo with unsearchable commits? The bad idea is using the fork functionality to create an unrelated copy of a repo, in the first place.

I suppose the other option is to convince the maintainer of the parent repo to fall on their sword, and delete that repo instead. If the parent repo of a fork network is deleted, one of the forks becomes the new parent — it’s not detailed exactly how that choice is made, but presumably it’s either made by the parent repo’s owner during the deletion process, or it’s automatic in which case “most-starred fork” is a safe assumption.

If that’s an option, then I agree that deleting/recreating the fork is a worse one. But parent-repo seppuku isn’t likely to be an option, most of the time.