How to Clone Only a Specific Branch in Git

Today, we are going to dive a bit deeper into how Git repositories are handled.

When someone tells you to “clone the repository," do you just run git clone [URL] without thinking?
For a small personal project, that’s totally fine. However, doing that on a long-running project or a poorly managed repository is a waste of time and resources.

In this article, we’ll introduce a technique to “bring over only the branch you actually need, right where you need it."

目次

Putting Bloated Repositories on a Diet

Why would you need to clone only a specific branch?
The biggest reason is “repository bloat caused by past mistakes."

Accidents happen in development environments.

  • Massive test video files that were accidentally committed
  • node_modules or vendor directories left in the history due to missing .gitignore settings
  • High-resolution design assets that are no longer in use

These may have already been deleted and no longer exist in the current main branch. However, due to how Git works, a standard clone will download all of this garbage data as “past history from other branches that are no longer in use."
Consuming gigabytes of network bandwidth and disk space for files irrelevant to the branch you want to work on right now is a waste.

Getting Only the Code You Need, as Fast as Possible

Our goal today is simple:

  1. Target: Retrieve data only for the “specific branch" you need right now.
  2. Download Time: Significantly reduced compared to a full clone.
  3. Disk Usage: Keep past unnecessary data down to 0 bytes.

Especially when developing in metered CI/CD environments, VPS with limited storage, or IoT devices like Raspberry Pis, this “diet" directly impacts cost and performance.

The Tragedy of “Just Full-Clone Everything"

Cloning all data without thinking comes with the following disadvantages:

  • Wasted Waiting Time: In slow network environments or when tethering, downloading gigabyte-scale data is fatal.
  • CI/CD Bottlenecks: Every time a pipeline runs, unrelated history is fetched, increasing the waiting time until the build starts and driving up cloud execution costs.
  • Increased Noise: Running git branch -a displays hundreds of lines of work branches left behind by people you don’t even know. This increases cognitive load and causes human errors (such as merging into the wrong branch).

Your toolbox should be organized with only the tools you use right now.

[The Solution] The Combination of -b and --single-branch

Let’s get straight to the point. Use the following command:

git clone -b <branch-name> --single-branch <repository-URL>

Anatomy of the Options

Many people are satisfied with just -b (specifying the branch), but that alone is not enough.

  • -b <branch-name>: This merely checks out that branch after the clone completes. Under the hood, it is still downloading data for all branches.
  • --single-branch: This is the main event. It restricts the download target to “only the history of the specified branch." Information about other branches is not even saved in the .git directory.

Execution Example

For instance, if you only need a branch named fix/nando-patch:

git clone -b fix/nando-patch --single-branch https://github.com/user/repo.git

With this, massive legacy files lurking in other branches will not be downloaded at all.

Common Misconceptions and Recovery Methods

You might worry, “Does using this option make things inconvenient?" Let’s clear that up right now.

Q1. Can I create a new branch from this state?

A. Yes, you can.
A lot of people misunderstand this, but the only restriction is “viewing other people’s remote branches."
There is absolutely no problem with creating a derived branch using git checkout -b my-new-feature based on the code you brought locally and proceeding with your work.

Q2. What if I later decide, “Actually, I want to see all the branches after all"?

A. You can revert it by rewriting the settings.
If development progresses and you find you truly need information from other branches, you can lift the restrictions with the following steps:

1. Rewrite the tracking target in the config to “all branches"

git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"

2. Fetch the information again

git fetch origin

This will return the repository to the same state as a normal one. Rest assured, this is not an irreversible operation.

Conclusion

Simplicity is the ultimate efficiency. Criteria for choosing your approach:

  • Small-scale personal development: Standard git clone is fine.
  • CI/CD and Deployments: Essential. Make it as fast and lightweight as possible, even by a second.
  • Long-running, massive repositories: Essential. To keep legacy files out of your local environment.

Git is a convenient tool, but using it mindlessly impairs your Developer Experience (DX). “Only what you need, exactly when you need it." This is a golden rule that applies equally to DIY and server management.
Be sure to register this in your local aliases and maintain a clean development environment free of wasted data.