Git Clone Into a Specific Directory

{/* Secondary: Git, GitHub, repository, branch, commit, origin remote, working directory, SSH key, shallow clone. Context entities: terminal, VS Code, HTTPS, port 22, .git suffix, CI pipeline, Docker. Root attributes: target folder name, default naming, empty-directory rule, clone-in-place (dot), branch selection, depth. Unique/info-gain: clone-into-current-dir with dot, --single-branch + --branch combo, fetch --unshallow recovery, error-message-to-fix table, sparse-checkout for partial trees. */}

Run git clone <url> <folder-name> and Git writes the repository into the folder you name instead of the default one. The folder name is the last argument on the command line, after the repository URL. That single extra word is the whole trick, and the rest of this guide covers when you reach for it, the errors that block it, and the clone variants that go with it.

By default Git names the new folder after the repository, so the URL decides where your files land. Naming your own target folder keeps a workspace tidy when you clone several related repositories, when a project name clashes with a folder you already have, or when a build script expects a fixed path. The examples below use a public GitHub URL, but every command works the same on GitLab, Bitbucket, Azure Repos, and self-hosted Git.

What git clone does and where files land

git clone copies a remote repository onto your machine and sets up the link back to it. Git downloads the full commit history, checks out the default branch into a working folder, and records the source URL as a remote named origin. From that point you can fetch new commits, branch, commit your own work, and push it back.

Git is a distributed version control system, which means your clone is a complete repository, not a thin checkout. Every commit, branch, and tag lives in the local .git folder, so you can read the entire history offline and switch branches without touching the network.

When you skip the folder argument, Git derives the destination name from the URL by stripping the trailing .git:

git clone https://github.com/username/myproject.git

This creates a folder named myproject inside your current working directory and fills it with the repository contents. Useful, but you gave up control of the name. The next section takes it back.

How to clone into a specific directory

Add the folder name as the final argument and Git uses it instead of the default. The argument order is fixed: command, then URL, then target folder.

git clone https://github.com/username/myproject.git my-local-project

Git clones myproject into a folder called my-local-project in your current directory. The remote is still recorded as origin, so git fetch, git pull, and git push all keep working under the new name. The folder name is a purely local label.

The target path is relative to where you stand in the shell, and it can be nested. Git creates intermediate folders that do not yet exist:

git clone https://github.com/username/myproject.git ~/code/clients/acme/api

That command clones straight into ~/code/clients/acme/api, building the clients and acme folders along the way if they are missing. One command, exact placement, no cd and rename dance afterward.

Clone into the current directory with a dot

Pass a single dot as the target and Git clones the contents into the folder you are already in, with no subfolder wrapper:

mkdir api-service
cd api-service
git clone https://github.com/username/myproject.git .

The repository files land directly inside api-service. This pattern fits a folder you set up in advance, a path your tooling already points at, or a deploy directory. The catch: the current folder must be empty, or Git stops with an error. The next section covers that case.

Handling a target directory that already exists

Git refuses to clone into a folder that already holds files, which protects you from overwriting work by accident. When the target exists and is not empty, the clone stops with this message:

fatal: destination path 'my-local-project' already exists and is not an empty directory.

You have three clean ways out, depending on whether the existing contents matter.

Rename the existing folder

When the current folder holds files you want to keep, move it aside first, then clone into the freed-up name:

mv my-local-project my-local-project-backup
git clone https://github.com/username/myproject.git my-local-project

Your old files sit safely in my-local-project-backup, and the fresh clone takes the original name. Copy back anything you need afterward.

Clone elsewhere, then move the contents

When the folder must exist before the clone (a deploy target, for instance), clone to a temporary name and move the files in:

git clone https://github.com/username/myproject.git tmp-clone
mv tmp-clone/* tmp-clone/.git my-existing-folder/
rmdir tmp-clone

The .git folder is hidden, so name it explicitly in the mv or the clone loses its repository link. A plain mv tmp-clone/* leaves .git behind and turns your code into an ordinary folder with no history.

Delete the existing folder

When the contents are disposable, remove the folder and clone fresh. Treat rm -rf with respect, since it deletes permanently with no recycle bin:

rm -rf my-existing-folder
git clone https://github.com/username/myproject.git my-existing-folder

Confirm the path before you press Enter. A stray space or wrong name in an rm -rf is one of the fastest ways to lose data on the command line.

Faster and smaller clones with depth and branch flags

Three flags shrink the download or narrow what Git fetches, and each pairs with a target folder. They matter most for large repositories, slow connections, and automated builds where a full history is wasted bandwidth.

| Flag | What it fetches | Best for | | --- | --- | --- | | --depth 1 | Only the latest commit | CI jobs, Docker builds, one-off checkouts | | --branch <name> | Checks out a named branch after cloning | Working on a release or feature line | | --single-branch | History of one branch only | Trimming a multi-branch repository |

Shallow clone with --depth

A shallow clone copies only the most recent commit instead of the full history, so it finishes faster and uses less disk:

git clone --depth 1 https://github.com/username/myproject.git my-project

This is the standard choice in CI pipelines and Dockerfiles, where you build from the current code and never need old commits. If you later need the full history, convert the shallow clone in place:

git fetch --unshallow

Clone a specific branch

Git checks out the default branch unless you point it elsewhere. The --branch flag (short form -b) accepts a branch or a tag name:

git clone --branch develop https://github.com/username/myproject.git my-project

Pair it with --single-branch to download only that branch and skip the rest, which keeps the clone small on a repository with many branches:

git clone --branch develop --single-branch https://github.com/username/myproject.git my-project

Sparse checkout for one subfolder

When you want the history but only part of the file tree, a sparse checkout pulls a subfolder instead of the whole project. It suits monorepos where a single package is all you touch:

git clone --no-checkout https://github.com/username/monorepo.git my-package
cd my-package
git sparse-checkout set packages/billing
git checkout

Git keeps the full history available while the working folder holds only packages/billing.

Clone over SSH instead of HTTPS

Cloning over SSH authenticates with a key on every fetch and push, so you stop typing a username and token each time. After you add an SSH key to your Git host, use the SSH form of the URL, and a target folder still works as the last argument:

git clone git@github.com:username/myproject.git my-project

HTTPS stays the better option behind firewalls that block port 22 or on shared machines where storing a key is awkward. The folder argument behaves the same either way, since the protocol changes only how Git authenticates, not how it names the destination.

Common errors and their fixes

The clone failures below all surface as Git messages in the terminal. Each maps to a direct fix.

| Error message | Cause | Fix | | --- | --- | --- | | destination path '...' already exists and is not an empty directory | Target folder holds files | Rename, empty, or pick a new target name | | repository '...' not found | Wrong URL or no access | Check the URL, confirm read access, sign in | | Permission denied (publickey) | SSH key missing or not added to the host | Add your public key to the Git host account | | could not create work tree dir: Permission denied | No write permission in the current folder | cd to a folder you own, or fix permissions | | fatal: Remote branch X not found in upstream origin | --branch names a branch that does not exist | List remote branches, correct the name |

After any clone, run git remote -v inside the new folder to confirm origin points at the right URL, and git branch to see which branch you checked out.

Where this fits in your Git workflow

Cloning is the entry point: it gets a repository onto your machine so you can branch, commit, and push. Naming the target folder is a small habit that keeps a multi-project workspace readable and stops path clashes before they start. Once the code is local, the next steps are creating branches and merging them, which the Git branch merge guide walks through with worked examples.

Git commands are precise about syntax, and a single misplaced argument produces an error that reads cryptically at first. If your terminal output looks confusing, our guide to decoding syntax errors shows how to read an error message back to its cause. When an assignment leans on Git workflows you have not used before, the developers behind our do my programming homework service work in Java, C++, Python, JavaScript, and SQL, and explain the version-control steps alongside the code so you can defend the work yourself.

Frequently asked questions

How do I clone a Git repository into a specific directory?

Add the target folder name as the last argument: git clone https://github.com/username/myproject.git my-folder. Git creates my-folder in your current location and writes every file into it, ignoring the default name from the URL. The folder must be empty or not yet exist.

What is the default directory name when you run git clone?

Git uses the repository name from the end of the URL with the .git suffix removed. Cloning https://github.com/username/myproject.git creates a folder named myproject in your current working directory. Passing a name after the URL overrides this.

Can I clone a repository into the current directory?

Yes. Pass a single dot as the target: git clone <url> .. Git clones the contents straight into the folder you are in, with no subfolder. The current directory must be empty, or Git stops with the message that the destination already exists and is not empty.

Why does git clone say the destination path already exists and is not empty?

Git refuses to clone into a folder that holds files, so it never overwrites your work. Pick a new target name, rename the existing folder with mv old-name old-name-backup, or empty the folder if its contents are disposable. Then run the clone again.

How do I clone only a single branch in Git?

Use git clone --branch branch-name --single-branch <url> my-folder. The --branch flag checks out that branch after cloning, and --single-branch fetches only its history instead of every branch, which keeps the download small.

What does git clone --depth 1 do?

It creates a shallow clone with only the latest commit and skips the full history, so the download is faster and smaller. This suits CI pipelines, Docker builds, and one-off checkouts. Run git fetch --unshallow later to pull the rest of the history when you need it.

When should I clone over SSH instead of HTTPS?

Clone over SSH when you push often and want to stop typing credentials. After you add an SSH key to your Git host, git clone git@github.com:username/myproject.git authenticates with the key on every fetch and push. HTTPS is better behind firewalls that block port 22 or on machines where you cannot store a key.

Does cloning into a named directory change the remote repository?

No. The folder name affects only your local copy. Git records the source URL as the remote named origin no matter what you call the folder, so fetch, pull, and push keep working. You can rename the local folder later without breaking the connection.