Git Clone or Push Slow

Git Clone Time Breakdown

A git clone involves three distinct phases, each with its own bottleneck. First, the server generates a packfile containing all the objects needed for the clone — this is server-side CPU work that can take seconds to minutes on large repositories. Second, the packfile is transferred over the network — this is where your download speed matters. Third, Git unpacks and indexes the received objects locally — this is CPU and disk I/O on your machine. When a clone feels stuck, check which phase you are in before assuming the network is slow.

Find the Type of Slowness

Fix 1: Shallow Clone and Single-Branch Clone

If you only need the latest code — for CI/CD, quick testing, or read-only reference — a shallow clone avoids downloading the entire commit history:

git clone --depth 1 --single-branch -b main https://example.com/org/repo.git

The --depth 1 flag fetches only the most recent commit on the specified branch. The --single-branch flag tells Git not to fetch refs for any other branches, which can significantly reduce the number of objects transferred on repositories with many long-lived branches.

Do not use shallow clones for release work, blame and bisect operations, or tools that need full commit history. For CI/CD where full history is not needed, shallow clones can reduce clone time from minutes to seconds on large repositories.

Fix 2: Git Bundle for Cloning Over Slow Links

If you need to set up a full clone over a slow or metered connection, create a git bundle on a fast network, transfer the file via any means (USB, file sharing), and clone from the bundle locally:

git bundle create repo.bundle --all
git clone repo.bundle my-repo

After cloning from the bundle, update the remote URL to the real origin and fetch only the delta since the bundle was created. This is especially useful for large monorepos in locations with poor connectivity to the hosting service.

Fix 3: SSH vs HTTPS Performance

SSH and HTTPS take different network paths and are subject to different filtering. SSH uses port 22, which some corporate firewalls block or route through inspection appliances that add latency. HTTPS uses port 443, which is almost never blocked and often has HTTP/2 support on modern Git hosting (GitHub, GitLab, Bitbucket all support HTTP/2 over HTTPS), which reduces connection overhead for sequential operations.

If SSH clones are slow or hang, try HTTPS and compare. If HTTPS is slow behind a proxy but SSH works cleanly, use SSH. The better protocol is whichever one your network path handles without interference. You can configure SSH multiplexing in ~/.ssh/config to reuse connections across consecutive Git operations:

Host github.com
  ControlMaster auto
  ControlPath ~/.ssh/control-%r@%h:%p
  ControlPersist 600

This keeps the SSH connection alive for 10 minutes, avoiding repeated handshakes when running multiple git fetch, pull, or push commands in succession.

Fix 4: Git LFS and Large Binary Files

Repositories that use Git LFS for large binary files (images, videos, design assets, datasets) clone in two stages: the regular git objects clone quickly, and then LFS objects are downloaded separately. If a clone finishes fast but the working directory is missing large files or shows pointer files, the LFS download is the slow part. Check .gitattributes for tracked LFS extensions and use git lfs ls-files to see what is tracked.

If the repository does not use LFS and large binaries were committed directly into history, the history itself carries that weight forever. Use git count-objects -vH to see how much disk space the local object store occupies. Repositories with gigabytes of history are genuinely slow to clone and the only permanent fix is rewriting history with git filter-repo to remove the large objects.

Fix 5: Large Pushes and http.postBuffer

Push speed is limited by your upload bandwidth. A 500 Mbps download plan with 10 Mbps upload will make large pushes painful. If you are pushing a large initial commit, rewritten history, or many LFS objects, upload speed is the hard ceiling.

For large HTTPS pushes that fail with buffer errors, increase the Git HTTP post buffer:

git config --global http.postBuffer 524288000

This sets the buffer to 500 MB, which prevents chunking failures on large pushes over HTTPS. It does not increase speed, but it prevents certain timeout and buffer-overflow failures on slow connections.

Fix 6: Disable VPN or Proxy for One Controlled Test

Git traffic can be slowed by SSL inspection, data loss prevention tools, corporate proxies, and VPN gateways. If policy allows, test one clone on the normal network and one through VPN. If the difference is large, bring that result with timing data to your IT team instead of endlessly tuning Git configuration. Ask specifically about allowlisting the Git hosting domain for split tunneling or bypassing TLS inspection.

Frequently Asked Questions

Why is git clone slower than downloading a zip file?

A Git clone downloads the full commit history, all objects for every tracked file across every version, tags, branch refs, and LFS pointers — then indexes them locally. A zip file contains only the current snapshot of the working directory without any history.

Does shallow clone make Git faster?

Yes, when you only need the latest state. A shallow clone with depth 1 avoids downloading most history and can reduce clone time dramatically on large repositories. It is not appropriate for release work, history analysis, or git bisect operations.

Why is git push slow?

Push speed is bounded by your upload bandwidth, the size of new objects being sent, any Git LFS uploads, server-side pack processing time, and whether VPN or proxy inspection is slowing the HTTPS or SSH connection.