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.

14 Likes

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

14 Likes

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.

4 Likes

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 https://github.com/daattali/beautiful-jekyll 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.

2 Likes

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.

1 Like

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