Introduction

To clone a Git repository into a specific folder, pass the target directory as the second argument to git clone:

git clone <repository-url> <target-folder>

Git will create that folder, initialize a .git directory inside it, fetch the remote history, and check out the default branch. If you omit the second argument, Git derives the folder name from the repository URL. The rest of this article covers the variations, edge cases, and related workflows you will encounter when controlling where your cloned repositories land.

Basic Clone Into a Named Folder

git clone https://github.com/example/project.git my-project

This creates a directory called my-project in your current working directory. Inside it, you get the full working tree plus the .git metadata directory.

The target folder can also be an absolute path:

git clone https://github.com/example/project.git /opt/apps/my-project

Or a relative path with subdirectories (Git creates intermediate directories as needed):

git clone https://github.com/example/project.git projects/backend/my-project

What git clone Actually Sets Up

A clone does more than copy files. Understanding what it creates helps explain why it is the right tool for getting a new local copy:

A clone is a complete, independent copy of the repository. You can work offline, switch branches, and view full history without any network access after the initial clone.

Combining With Other Clone Options

The target folder argument works alongside every other git clone flag.

Clone a Specific Branch

git clone -b develop https://github.com/example/project.git my-project

This checks out the develop branch instead of the remote's default. The other branches are still fetched; only the initial checkout changes.

Shallow Clone (Latest Snapshot Only)

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

A shallow clone fetches only the most recent commit. This is significantly faster for large repositories when you only need the current state, not the full history. It is commonly used in CI/CD pipelines.

Shallow Clone of a Specific Branch

git clone --depth 1 -b v2.0 https://github.com/example/project.git my-project

Clone Without Checking Out a Working Tree

git clone --no-checkout https://github.com/example/project.git my-project

This fetches the repository but does not populate the working tree. Useful when you want to set up sparse checkout rules before materializing files.

Sparse Checkout (Specific Subdirectories Only)

For monorepos where you only need certain paths:

git clone --filter=blob:none --sparse https://github.com/example/monorepo.git my-project
cd my-project
git sparse-checkout set packages/frontend docs/

This downloads metadata for the full repo but only materializes the files under packages/frontend and docs/.

Clone via SSH

git clone [email protected]:example/project.git my-project

SSH cloning is the standard for repositories you have push access to. The target folder argument works identically with SSH and HTTPS URLs.

Cloning Into the Current Directory

If you want to clone into the current (empty) directory without creating a subdirectory:

mkdir my-project && cd my-project
git clone https://github.com/example/project.git .

The . target tells Git to use the current directory. This only works if the directory is empty. If it contains any files (even hidden ones like .DS_Store), the clone will fail.

What If the Folder Already Exists?

git clone refuses to clone into a non-empty directory. If the target folder exists and contains files, you will see an error like:

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

For this situation, you need the manual setup path:

1cd existing-folder
2git init
3git remote add origin https://github.com/example/project.git
4git fetch origin
5git checkout -t origin/main

This initializes a new repository in the existing folder, connects it to the remote, fetches the history, and checks out the main branch. It is not equivalent to a fresh clone because existing files may conflict with tracked files.

Another option is to clone into a temporary folder and then move the contents:

git clone https://github.com/example/project.git /tmp/repo-temp
cp -r /tmp/repo-temp/. existing-folder/
rm -rf /tmp/repo-temp

Multiple Working Copies

Specifying different target folders lets you maintain multiple working copies of the same repository for different purposes:

git clone https://github.com/example/project.git project-dev
git clone https://github.com/example/project.git project-review
git clone https://github.com/example/project.git project-experiment

Each clone is fully independent. Changes in one do not affect the others.

For a lighter-weight alternative, consider git worktree:

git clone https://github.com/example/project.git project-main
cd project-main
git worktree add ../project-feature feature-branch

Worktrees share the same .git object store, so they use less disk space and fetch history only once. However, each worktree must be on a different branch.

Quick Reference

Common Pitfalls

Trying to clone into a non-empty directory and expecting Git to merge the repository contents with existing files is the most common mistake. Git intentionally refuses this to prevent data loss. Use the git init and git remote add workflow for existing directories.

Forgetting that the target folder is just the second positional argument leads people to search for a --directory or --target flag that does not exist. The syntax is simply git clone URL folder.

Assuming the default branch is always main can cause errors in the manual setup path. Some repositories use master, develop, or a custom default. Check with git remote show origin to see the remote HEAD.

Using --depth 1 for a repository you plan to contribute to creates problems later. Shallow clones lack the history needed for rebasing, blame, and log commands. Only use shallow clones for read-only or CI contexts.

Cloning large repositories over HTTPS when SSH keys are available wastes time on repeated credential prompts and misses out on connection multiplexing benefits.

Mixing up git clone URL . with git clone URL ./ does not cause issues (they are equivalent), but confusing either with git clone URL (no second argument) means Git will create a subdirectory named after the repo instead of using the current directory.

Summary

• Pass the destination folder as the second argument to git clone: git clone URL my-folder.
• The target can be a relative path, absolute path, or . for the current directory.
• Combine with -b, --depth, --sparse, or --no-checkout for specialized clone workflows.
• git clone requires the target to be empty or non-existent. For existing directories, use git init plus git remote add.
• Consider git worktree instead of multiple full clones when you need parallel working directories for the same repository.