Create a GitHub Repository Safely with gh repo create

You will create a GitHub repository from the command line, choose its visibility deliberately, and verify the result without accidentally publishing the wrong files. Allow about five minutes for a new empty repository, or ten minutes when you are attaching an existing local project. The examples use the GitHub CLI command gh repo create.

1. Check the installed command and sign-in state

This guide was checked with GitHub CLI 2.87.3, released 23 February 2026. Your version may differ, so inspect the local help before relying on a newer option. You need the gh executable and an authenticated GitHub account with permission to create a repository in the selected owner or organisation.

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

If authentication is not ready, stop and complete it with your normal GitHub CLI sign-in process. Do not put an access token in a shell command, a script, or a repository URL. The repository command itself does not require sudo; elevated privileges are not a substitute for GitHub authorisation.

2. Choose visibility before creating anything

A non-interactive command must include one of --public, --private, or --internal. Treat this as a safety checkpoint. Public exposes the repository to everyone. Private limits access according to GitHub permissions. Internal is for an organisation and is not a general replacement for private repositories.

Review the owner and name as well. If you omit the OWNER/ part, the command uses the authenticating user. An organisation name is not a harmless label: it changes where the repository is created and who may administer it.

When you are ready to create a new public repository and clone it into the current directory, the command is:

$ gh repo create example-project --public --clone

The command creates the remote repository and clones it locally. Check the current directory before using --clone, because the clone destination must be suitable for a new directory. Verify the remote without changing it:

$ git -C example-project remote -v
origin  https://github.com/YOUR-ACCOUNT/example-project.git (fetch)
origin  https://github.com/YOUR-ACCOUNT/example-project.git (push)
$ gh repo view YOUR-ACCOUNT/example-project

3. Create an empty remote with useful metadata

For an empty repository, add a description, homepage, or initial README explicitly. A README changes the remote contents, so decide whether your local project should instead provide the first commit.

$ gh repo create YOUR-ACCOUNT/example-project \
    --private \
    --description "Example project maintained by the team" \
    --homepage "https://example.invalid/example-project" \
    --add-readme

After creation, inspect the repository page and its visibility:

$ gh repo view YOUR-ACCOUNT/example-project
$ gh repo view YOUR-ACCOUNT/example-project --json name,visibility,url

Do not put passwords, API keys, private customer data, or generated build output into a public repository. The --disable-issues and --disable-wiki flags change the new repository's features; use them only when that policy is intentional.

4. Attach an existing local repository

Use --source when the project already exists locally. Inspect its status and remotes first. This is a checkpoint: the source directory may contain files you did not mean to publish.

$ cd /path/to/YOUR-PROJECT
$ git status --short
$ git log -1 --oneline
$ git remote -v

Review ignored files and tracked files too. A secret that is already tracked is still part of the commit history even if you add it to .gitignore now. Remove and rotate exposed credentials before creating or pushing the repository.

Create a private remote and name the local remote explicitly:

$ gh repo create YOUR-ACCOUNT/example-project \
    --private \
    --source=. \
    --remote=origin

By default, the remote repository name comes from the source directory when no name is supplied. The --remote value controls the local Git remote name, not the GitHub owner or repository name.

5. Push local commits only after reviewing them

Creating the remote does not automatically mean that all local commits should be sent there. Inspect the branch, recent commits, and remote URL. Then add --push to the creation command, or push through Git after the remote has been checked.

$ git branch --show-current
$ git log --oneline -5
$ git remote get-url origin
$ git push --set-upstream origin YOUR-BRANCH

If you want gh repo create to perform the push while it creates the repository, use the same source workflow with --push:

$ gh repo create YOUR-ACCOUNT/example-project \
    --private \
    --source=/path/to/YOUR-PROJECT \
    --remote=origin \
    --push

For a template repository, pass --template OWNER/TEMPLATE. Add --include-all-branches only when every template branch is wanted. A template or an existing source is not a clean-room operation: review its files and history before sharing it.

6. Recover from a mistake

There is no undo flag in gh repo create. If the command created the wrong remote, stop before pushing and confirm the repository name and owner in GitHub. Remove the unwanted repository through its GitHub repository settings only after checking that it contains no needed work. Repository deletion is irreversible unless you have an independent copy, so do not turn it into an automatic cleanup step.

If a push failed, keep the local commits. Check the error, confirm the remote URL, and retry only after verifying visibility and access:

$ git remote -v
$ gh repo view YOUR-ACCOUNT/example-project
$ git push

If you created the remote with the wrong visibility, change that setting in GitHub after checking who may already have accessed it. If a secret was pushed, rotate it first; changing visibility or deleting a file does not make a credential safe.