Clone Remote Git Repository: Clone, Verify & Show Origin (2026)

You've got a URL — from GitHub's green "Code" button, a teammate's Slack message, or a package.json repository field — and you need a working local copy. The command to clone remote git repository content is git clone <url>, and ninety percent of the time that's the entire job. This guide covers that command plus the part almost nobody explains well: where the clone actually lands on disk, six different ways to check what origin a clone is pointed at after the fact, and when a shallow or partial clone saves real time on a large repository. If you need to change an existing clone's remote URL instead of creating a new one — switching hosts, fixing a typo, moving from HTTPS to SSH on a repo you already have — that's a different operation covered in full in the git change remote URL guide; this article is entirely about the read side: cloning and inspecting, not mutating.

Quick Answer: Clone, Then Verify Origin

Pick your scenario — whether you got here searching "how to clone repo" or hunting for the exact flag that skips 90% of the download. Full explanations follow in the linked sections below.

The most common variants of this question — "how to git clone", "how to use git clone", and "how to clone a repository git" — are all answered by that first row. Everything past it is about what happens next: confirming the clone landed where you expected and is pointed at the URL you think it is, which matters more than most tutorials let on once you're juggling forks, mirrors, and multiple accounts on the same host.

What git clone Actually Does

git clone <url> does four things in one command. Understanding all four is what separates "I typed the command and it worked" from actually knowing what you have on disk after you clone remote git repository content:

• Downloads the full object database. By default, every commit, tree, and blob reachable from every branch and tag on the remote — not just the current branch's latest snapshot. This is why a clone of a repository with fifteen years of history can take longer than checking out a fresh copy would suggest.
• Creates a working directory checked out to the remote's default branch (whatever HEAD points to on the server — typically main or master, not necessarily either by name).
• Configures a remote named origin pointing at the URL you cloned from, stored in .git/config under [remote "origin"]. This is the same block that git remote set-url edits later — cloning is simply the first time that block gets written.
• Sets up branch tracking so the local default branch (e.g., main) has branch.main.remote = origin and branch.main.merge = refs/heads/main, meaning a bare git pull immediately knows where to fetch from without any extra configuration.

$ git clone https://github.com/acme/app.git
Cloning into 'app'...
remote: Enumerating objects: 4213, done.
remote: Counting objects: 100% (4213/4213), done.
remote: Compressing objects: 100% (1802/1802), done.
Receiving objects: 100% (4213/4213), 3.21 MiB | 5.44 MiB/s, done.
Resolving deltas: 100% (2140/2140), done.

That entire sequence — enumerate, count, compress, receive, resolve deltas — is git's object transfer protocol doing its job; none of it is configurable per se, though the large-repo section below covers flags that shrink what gets transferred in the first place.

Where Does git Clone To? The Directory Naming Rules

This is the literal answer to "when i clone a repository where does it go" and "where does git clone to": a new directory created directly inside your current working directory — wherever your shell's prompt is when you run the command. Git does not clone to a fixed system location, your home folder, or anywhere related to where other repos live; it's always relative to where you typed the command. If that surprises you after a clone, check pwd before you ran it, not git's configuration.

The folder's name follows what git's own git-clone documentation calls "humanish" logic — derived from the URL, not chosen at random:

• Take the last path component of the URL (everything after the final /).
• Strip a trailing .git suffix if present.
• Strip a trailing slash first, if the URL happened to end with one, before applying the above.

# All four of these clone into a directory literally named "app"
git clone https://github.com/acme/app.git
git clone https://github.com/acme/app
git clone git@github.com:acme/app.git
git clone https://github.com/acme/app.git/

Override the name explicitly with a second argument — that's how to git clone into a folder that doesn't match the repository's own name, useful when you're cloning the same repo twice for a side-by-side comparison, or the upstream name collides with something you already have:

# Clone into a directory named "app-staging" instead of "app"
git clone https://github.com/acme/app.git app-staging

# Clone into the CURRENT directory — must already exist and be empty
git clone https://github.com/acme/app.git .

Two failure modes are worth knowing before they surprise you mid-script. First, if the target directory already exists and is not empty, git refuses outright rather than merging or overwriting anything:

$ git clone https://github.com/acme/app.git
fatal: destination path 'app' already exists and is not an empty directory.

Second, an empty directory is fine — git clone <url> . into an empty current directory works and initializes the repo right there, which is the pattern behind "clone into the folder I already made and cd'd into," a common step in CI job definitions that pre-create a workspace directory before checkout.

How to Find a GitHub Repository URL

Answering "how to find github repository url" and "how to get github repository url" — on any repository's GitHub page, the green Code button opens a small panel with HTTPS, SSH, and GitHub CLI tabs, each showing the exact string to paste into git clone, as GitHub's own "Cloning a repository" docs walk through screen by screen. GitLab and Bitbucket use the same pattern under a Clone button, with the same two protocol choices.

Worth separating two questions that get phrased almost identically: this section is about finding the address of a repository you have not cloned yet. If the project is already on your disk, you never need the web page — a "github get remote url" or "github check origin" check runs entirely locally against .git/config, and the six commands for that are in the inspection section below.

Without web access to that page, "how to find github repository url" has a second answer: the URL is reconstructable from the pattern itself once you know the owner and repo name — which is what you fall back on when you're working from a CI log, a README, or a package manifest instead of the site:

# HTTPS pattern
https://github.com/<owner>/<repo>.git

# SSH pattern
git@github.com:<owner>/<repo>.git

# GitHub CLI, if you have gh installed and authenticated
gh repo clone <owner>/<repo>

gh repo clone is worth mentioning because it handles one annoyance automatically: it picks HTTPS or SSH based on your existing gh authentication setup, so you don't have to remember which protocol you configured credentials for on that particular machine.

HTTPS vs SSH: Choosing a Clone URL

Both protocols clone the identical repository content — the choice is entirely about how authentication and network access behave, not about what you end up with on disk.

Cloning a public repository over HTTPS needs zero setup — no key, no token, no login prompt. The friction shows up only on private repositories or on push, which is one reason a plain clone of an open-source project "just works" while cloning your own private fork sometimes doesn't until credentials are in place. Modern Git installers ship configured against an OS-managed credential store rather than the older plaintext store helper — osxkeychain on macOS, Git Credential Manager on Windows — which is worth knowing about if you're troubleshooting an unexpected credential prompt or a token that seems to have vanished after an upgrade. Check yours with git config --get credential.helper.

# Clone the same repository either way — content is identical
git clone https://github.com/acme/app.git
git clone git@github.com:acme/app.git

If you clone with one protocol and later decide the other suits you better, that's a URL change on an existing clone, not a re-clone — covered with full credential-fallout detail in the git change remote URL guide's HTTPS/SSH section.

Git Show Remote URL: Six Ways to Check Origin

Once a clone exists, the next question is almost always what it's actually pointed at. Whether you'd phrase that as git show remote url, check git remote url, or git check origin, it's the same question, and it has six possible answers. Which one you want depends on three things: whether you can afford a network round trip, how much detail you need, and whether a script has to consume the output.

1. git remote -v — the everyday answer to "see remote url git" and "git list remote url." Lists every configured remote with both its fetch and push URL, entirely from local config, instantly:

$ git remote -v
origin  https://github.com/acme/app.git (fetch)
origin  https://github.com/acme/app.git (push)

2. git remote show origin — the full answer to "git show origin" and "git view origin." This one actually contacts the server, so it's slower and needs a working network connection and valid credentials for private repos, but it returns tracking-branch detail nothing else does:

$ git remote show origin
* remote origin
  Fetch URL: git@github.com:acme/app.git
  Push  URL: git@github.com:acme/app.git
  HEAD branch: main
  Remote branches:
    main   tracked
    dev    tracked
  Local branches configured for 'git pull':
    main merges with remote main
  Local refs configured for 'git push':
    main pushes to main (up to date)

3. git remote show origin -n — the same output shape as above, minus the remote-branch and push/pull status lines, because the -n flag skips contacting the server entirely. Use it when you want the local config summary without the network round trip.

$ git remote show origin -n
* remote origin
  Fetch URL: git@github.com:acme/app.git
  Push  URL: git@github.com:acme/app.git
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    main
    dev

4. git config --get remote.origin.url — the script-friendly single-value form, and the most direct answer to "git see origin url." Prints exactly one line with nothing else, and returns exit code 1 if origin isn't configured at all — useful in a shell script's conditional without parsing any other command's output:

$ git config --get remote.origin.url
https://github.com/acme/app.git

$ echo $?
0

5. git remote get-url --all origin and git config --get-regexp '^remote\.' — for a remote that has more than one URL configured (via set-url --add), the single-value form above only shows the first. get-url --all lists every fetch URL on that remote; the regexp form dumps every remote-related key in one shot, useful when you have several remotes and want everything at once rather than querying one name at a time:

# All fetch URLs on origin, one per line
git remote get-url --all origin

# Every remote.* key across all configured remotes
git config --get-regexp '^remote\.'
# remote.origin.url https://github.com/acme/app.git
# remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
# remote.upstream.url https://github.com/original-owner/app.git
# remote.upstream.fetch +refs/heads/*:refs/remotes/upstream/*

A related asymmetric case: if fetch and push are configured to different URLs (via set-url --push), git remote get-url origin alone only shows the fetch URL. Ask for the push URL specifically:

git remote get-url origin --push

6. Reading .git/config directly, or git ls-remote <url> to test a URL before cloning. The config file is plain text — cat .git/config or opening it in any editor shows the [remote "origin"] block verbatim, which is occasionally faster than remembering a command when you're already looking at the file for another reason. Going the other direction — checking a URL before you commit to a full clone — git ls-remote queries a remote's refs without downloading a single object:

# Read the raw config
cat .git/config

# Confirm a URL is reachable and see its branches/tags — no clone happens
git ls-remote https://github.com/acme/app.git
# a1b2c3d4...  HEAD
# a1b2c3d4...  refs/heads/main
# e5f6a7b8...  refs/heads/dev
# c9d0e1f2...  refs/tags/v1.0.0

git ls-remote pays off twice: once before cloning, to confirm a URL actually resolves, and again after — if you're comparing two remotes (a mirror against its source, or the same repo on two different hosts), running it against both and pasting the two ref lists into a side-by-side text diff surfaces any missing branch or tag instantly, rather than eyeballing two long lists by hand. Prefer staying in the terminal instead of a browser tab? The same comparison works with plain diff on the two saved outputs, covered in the Linux compare files guide.

Which Inspection Command to Use When

Side by side, so the choice is a lookup instead of a guess:

The one-line rule: reach for git remote -v by default — it covers what almost every version of this question is actually asking, from "git view remote url" to "git display remote url" — drop to git config --get the moment a script needs to branch on the result, and only pay the network cost of show origin or ls-remote when you specifically need server-side state — ahead/behind counts, or a ref list you don't have locally yet.

Cloning a Single Branch, Tag, or Directory

A default clone pulls every branch's history. When you only need one branch — a release branch, a specific tag, or just the current state of main — narrow the clone at the source instead of pruning branches afterward:

# Clone only the dev branch — no other branches are fetched
git clone --branch dev --single-branch https://github.com/acme/app.git

# Clone a specific tag — same flag, a tag name instead of a branch
git clone --branch v1.0.0 --single-branch https://github.com/acme/app.git

--single-branch restricts the fetch refspec so later git fetch and git pull calls only ever touch that one branch too — it's not a one-time shortcut, it changes the clone's ongoing behavior. Add every other branch back later with:

git remote set-branches origin '*'
git fetch origin

There's no native git clone flag for pulling down only one directory out of a repository — that's what sparse checkout is for, covered in the large-repos section next, since directory-scoped clones and large-repo clones solve overlapping problems with the same underlying feature. And once a feature branch from a single-branch clone has served its purpose — merged, or abandoned — cleaning it up locally is the same git branch -d/-D workflow covered in the git delete local branch guide, whether the clone pulled one branch or all of them.

Shallow, Partial, and Sparse Clones for Large Repos

A monorepo with a decade of history and gigabytes of binary blobs turns a plain git clone into a multi-minute operation you didn't need — most of the time you want the current state, not every commit since the project's first year. Four flags, each trimming a different dimension of what gets transferred:

# Shallow clone — just the latest commit, current branch
git clone --depth 1 https://github.com/acme/huge-monorepo.git

# Blobless partial clone — full history graph, file contents on demand
git clone --filter=blob:none https://github.com/acme/huge-monorepo.git

# Combine depth and branch scoping for the smallest practical clone
git clone --depth 1 --branch main --single-branch \
  https://github.com/acme/huge-monorepo.git

The real gotcha: --depth 1 --branch v1.0.0 works cleanly for a tag exactly like it does for a branch — git fetches only the single commit that tag points to, plus its combination with --single-branch means no other refs come along for the ride. Where people get surprised is afterward: a shallow clone's git fetch stays shallow by default too, so pulling later doesn't retroactively deepen history, and commands that need full history — git blame across old revisions, git bisect spanning more commits than you have — fail or behave unexpectedly until you deepen it:

# Convert a shallow clone to a full one when you need real history later
git fetch --unshallow

# Or deepen incrementally instead of fetching everything
git fetch --depth 50

For repositories where the pain is a huge working tree rather than long history — a monorepo where you only work in one subproject — sparse checkout narrows what's actually materialized on disk after a full (or partial) clone:

# Clone without checking out files yet
git clone --filter=blob:none --sparse https://github.com/acme/huge-monorepo.git
cd huge-monorepo

# Now materialize only the directories you actually need
git sparse-checkout set services/api docs

Stacking --filter=blob:none --sparse together is the combination that scales best on genuinely large repositories: the object graph download shrinks via the partial filter, and the working directory shrinks via sparse checkout, addressing the two separate costs — network transfer and disk/checkout time — independently.

Clone vs Fork vs Download ZIP

Three different things that all start from "I want this repository's code," and picking the wrong one is a common source of confusion, especially for "how to download a git repository" and "how to download git project" searches that assume clone is the only option.

The honest answer for "how to download repo" without git installed at all is the ZIP button — GitHub, GitLab, and Bitbucket all offer one on the repository's landing page. It's genuinely the simplest path for a one-off look at some code, but it is a dead end for anything ongoing: no commit history, no way to see what changed since you downloaded it, and no git pull to catch up later. If there's any chance you'll want to update the code or contribute back, clone instead — the extra .git folder is the entire point.

Fork sits between the two: it's a full clone's worth of history and update capability, just with an extra server-side copy under your account first, needed specifically because you lack write access to the original. If you already have push access to a repository — it's your own project, or you're a collaborator — forking is unnecessary overhead; clone the original directly. The fork-plus-upstream workflow, once you do need it, is covered in the fork workflow section of the remote URL guide.

Cloning Repositories with Submodules

A repository that references other repositories as submodules doesn't pull their content on a plain clone — you get an empty directory at each submodule's path and have to fetch them separately unless you ask upfront:

# Clone and pull all submodules in one pass
git clone --recurse-submodules https://github.com/acme/app.git

# Already cloned without the flag? Initialize and fetch them after the fact
git submodule update --init --recursive

For a large repository with many submodules, combine the shallow-clone flags from above with submodule recursion to keep the whole tree lean rather than fetching full history for every nested repository:

git clone --recurse-submodules --shallow-submodules --depth 1 \
  https://github.com/acme/app.git

--shallow-submodules applies the same depth-1 truncation to each submodule that --depth 1 applies to the top-level repository, instead of pulling full history for every one of them by default.

Clone vs Pull: What "Pull a Repository" Really Means

Two searches that sound alike but mean different things: "how to pull github repository" and "how to pull git repository" are, in the vast majority of cases people typing them, actually looking for git clone — they don't have a local copy yet and want one. git pull is a different operation entirely: it updates a clone you already have with new commits from its remote. Running git pull in a directory that isn't already a git repository just errors out with fatal: not a git repository (or any of the parent directories): .git; it has nothing to bootstrap from.

# You don't have the repo yet — this is what you want
git clone https://github.com/acme/app.git

# You already have a clone and want the latest commits — this is pull
cd app
git pull

Put simply: clone is a one-time bootstrap that also configures origin and tracking automatically; pull is the repeatable "catch up" step you run afterward, as often as needed, against the remote clone already set up. So "how to pull github repository" almost always wants the first command, and the related phrasing "how to checkout a repository from github" does too, since there's nothing to check out until a clone exists locally; git checkout itself operates on branches and commits within an existing repo, not on a remote URL directly.

Once a clone is up and pulling routinely, day-to-day local mistakes are a separate concern from anything covered here — fixing a commit message or a forgotten file is a git commit amend, and unwinding a commit entirely, pushed or not, is the undo-last-commit guide's territory. Both operate on history you already have locally; neither one touches the origin URL this guide is about. And when a working copy has drifted far enough that deleting the folder and re-cloning starts to look appealing, resetting hard onto origin gets you the same clean state without re-downloading the history.

Troubleshooting Clone and Remote URL Errors

Six errors account for nearly every clone failure that isn't a straightforward typo.

remote: Repository not found.
fatal: repository 'https://github.com/acme/app.git/' not found

Cause: the repository is private and you're not authenticated as an account with access, the URL has a typo in the owner or repo name, or you're signed into the wrong GitHub account (a common trap when you maintain both a personal and a work account on the same machine). GitHub deliberately returns the same generic "not found" for a private repo you can't see as it does for a URL that's simply wrong, rather than leaking which repositories exist — so this error alone doesn't tell you which of the three it is; check the URL first, then your authenticated account, then whether you actually have access.

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Cause: SSH key not registered with the host, wrong key loaded in ssh-agent, or no key at all. Confirm with ssh -T git@github.com — a successful auth greeting rules the key out as the problem; a rejection confirms it. Switch to an HTTPS URL as an immediate workaround while you sort out the key.

fatal: could not read Username for 'https://github.com': terminal prompts disabled

Cause: classic CI/CD failure — the runner has no interactive terminal to prompt for credentials, and none are pre-configured. Fix by injecting a PAT into the URL as an environment variable at clone time, or by configuring a credential helper the CI system supports natively (most CI providers document their own preferred pattern — GitHub Actions' actions/checkout, for instance, handles this automatically using the workflow's built-in token).

fatal: destination path 'app' already exists and is not an empty directory.

Cause: covered in the directory-naming section above — pick a different target name, remove or empty the existing directory first, or clone into a fresh location entirely.

fatal: unable to access 'https://github.com/acme/app.git/': Failed to connect
to github.com port 443 after 21089 ms: Couldn't connect to server

Cause: a corporate proxy or firewall blocking outbound HTTPS, or a genuinely flaky connection timing out on a large initial fetch. Confirm proxy settings are visible to git specifically, not just the browser (git config --global http.proxy <proxy-url>), and consider a shallow clone (--depth 1) to reduce the data transferred over a slow or unstable link.

remote: Support for password authentication was removed on August 13, 2021.
fatal: Authentication failed for 'https://github.com/acme/app.git/'

Cause: typing an actual account password where GitHub expects a personal access token. Generate a PAT (or, for finer scoping, a fine-grained token) under GitHub Settings → Developer settings, and use it in place of a password — or switch the remote to SSH entirely and sidestep password-shaped credentials altogether.

Frequently Asked Questions

Quick answers to the questions that come up most often when you clone remote git repository content — where the folder lands, how to check what origin is set to afterward, and when "how to clone a repository git" is really asking about forking or a plain ZIP download instead.