Create a GitHub Fork with gh repo fork Without Losing Your Upstream

You will finish with a GitHub fork created from the command line, a deliberate choice about whether to clone it, and a checked set of Git remotes. The examples use GitHub CLI 2.87.3, the gh executable installed on this machine in September 2026. Forking changes remote GitHub state, so read the target and account details before you run the command.

Allow about ten minutes for a normal fork, longer if the repository is large. You need an authenticated gh session, permission to create the fork in the destination account or organisation, and a network connection. The command itself does not need sudo. Elevated privileges will not grant GitHub permissions and should not be used here.

1. Check the installed command and your starting point

Start with read-only checks. This confirms the executable and shows the exact options available on this installation:

$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh repo fork --help

Check authentication before starting a fork. If the status check reports an expired or missing login, fix that with your normal GitHub CLI authentication process and stop there until it succeeds. Do not paste tokens into this command or into a shell history.

If you are already in a Git checkout and intend to fork its current repository, inspect the remotes before doing anything that may rename one:

$ git remote -v
origin  [email protected]:ORIGINAL_OWNER/REPOSITORY.git (fetch)
origin  [email protected]:ORIGINAL_OWNER/REPOSITORY.git (push)

The owner and repository shown above are placeholders. Replace them with the values printed on your machine.

2. Choose the repository and fork name

Pass a repository as OWNER/REPO when you are outside its checkout or want to be explicit:

$ gh repo fork ORIGINAL_OWNER/REPOSITORY --fork-name MY_FORK

With no repository argument, gh repo fork uses the current checkout's repository. That is convenient, but it is also an easy distraction trap: check git remote -v first so you do not fork a similarly named project from the wrong directory.

--fork-name changes the new repository's name. Leave it out to use the normal repository name. If that name already exists in your account, GitHub will reject the operation; do not work around that by deleting or overwriting an existing repository.

3. Decide whether the fork should be cloned

Without an explicit clone choice, the command can ask whether to clone the fork. Use a flag when the command will run unattended or when you want the result to be predictable:

$ gh repo fork ORIGINAL_OWNER/REPOSITORY --clone=false
- Forking ORIGINAL_OWNER/REPOSITORY...
✓ Created fork YOUR_ACCOUNT/REPOSITORY

To create and clone the fork in one operation, use --clone:

$ gh repo fork ORIGINAL_OWNER/REPOSITORY --clone
- Forking ORIGINAL_OWNER/REPOSITORY...
✓ Created fork YOUR_ACCOUNT/REPOSITORY
Cloning into 'REPOSITORY'...

The account name, directory name and progress output vary. The useful checkpoint is that GitHub reports the fork as created, followed by a local clone only when cloning was requested.

Cloning is a local filesystem change. Before using --clone, make sure the destination directory does not contain work you need. If Git refuses because the directory already exists, inspect it rather than removing it.

4. Choose remote handling explicitly

Remote handling is the part most likely to surprise an experienced Git user. The command's normal behaviour makes the fork origin. If the current checkout already has an origin, that remote is renamed to upstream; the original repository then becomes the default remote repository.

For a fork created from the current checkout, ask for the fork remote explicitly and skip the prompt:

$ gh repo fork --remote
- Forking ORIGINAL_OWNER/REPOSITORY...
✓ Created fork YOUR_ACCOUNT/REPOSITORY
✓ Renamed origin remote to upstream
✓ Added remote origin

To create the fork without changing local remotes, disable that behaviour:

$ gh repo fork ORIGINAL_OWNER/REPOSITORY --remote=false --clone=false

Use --remote-name when the fork should have a different local name:

$ gh repo fork ORIGINAL_OWNER/REPOSITORY --remote --remote-name my-fork --clone=false
$ git remote -v
my-fork  [email protected]:YOUR_ACCOUNT/REPOSITORY.git (fetch)
my-fork  [email protected]:YOUR_ACCOUNT/REPOSITORY.git (push)

The displayed URLs depend on your configured Git protocol. Check the actual output rather than assuming SSH or HTTPS.

5. Fork into an organisation or keep only the default branch

If you have permission to create repositories in an organisation, pass its name with --org:

$ gh repo fork ORIGINAL_OWNER/REPOSITORY --org TARGET_ORGANISATION --fork-name MY_FORK --clone=false

Organisation policy can still reject the request. A successful login to GitHub is not proof that you can create repositories in that organisation. Treat a permission error as an access problem, not as a reason to retry repeatedly.

For a smaller fork, add --default-branch-only:

$ gh repo fork ORIGINAL_OWNER/REPOSITORY --default-branch-only --clone=false

This asks GitHub to include only the source repository's default branch. It does not turn the fork into an independent repository and does not remove branches that already exist in an existing fork.

6. Verify the result

After the command succeeds, verify the repository in GitHub CLI:

$ gh repo view YOUR_ACCOUNT/MY_FORK
$ gh repo view YOUR_ACCOUNT/MY_FORK --json nameWithOwner,isFork,parent,defaultBranchRef

The JSON output should identify your fork and show its parent repository. Field output can vary with the CLI version and account visibility, so use the command's actual response as the authority.

If you cloned or added a remote, verify the local side too:

$ git remote -v
$ git remote get-url origin
$ git remote get-url upstream

Only ask for upstream if you deliberately kept or created one. With --remote=false, there may be no new local remote even though the GitHub fork exists.

7. Recover from an unwanted remote rename

Do not use a blind remote command if the repository contains work you care about. First save the current mapping:

$ git remote -v

If the fork is incorrectly named origin and the original repository is correctly named upstream, restore the old single-remote arrangement only after checking both URLs:

$ git remote remove origin
$ git remote rename upstream origin
$ git remote -v

git remote remove changes local Git configuration, not either GitHub repository. It does not delete the fork. If the URLs do not match that exact situation, stop and edit the remote configuration deliberately rather than applying this recovery sequence.