A git repository can be larger than the code, and slower on Windows

A checkout you can see is one copy of the code. The .git folder beside it holds every version of every file that repository has ever contained, which is why cloning something small can produce something large.

Finding the heavy ones

Get-ChildItem $env:USERPROFILE -Recurse -Directory -Filter .git -Force -Depth 5 -EA SilentlyContinue |
  ForEach-Object {
    $s = (Get-ChildItem $_.FullName -Recurse -Force -File -EA SilentlyContinue | Measure-Object Length -Sum).Sum
    [PSCustomObject]@{ MB = [math]::Round($s/1MB); Path = $_.FullName }
  } | Sort-Object MB -Descending | Select-Object -First 20

The routine cleanup

git count-objects -vH
git gc --aggressive --prune=now

gc repacks loose objects and drops anything unreachable, which on a repository with heavy branch churn can halve the folder. Nothing reachable from a branch, tag or the reflog is removed.

Git LFS caches

git lfs prune

LFS keeps its own cache under .git\lfs, holding versions of large files you no longer have checked out. On a repository that uses LFS this is frequently larger than the rest of the history, and pruning it is the biggest safe win.

Why Windows makes this feel worse

• Antivirus scanning. Defender scanning every file in a repository slows git operations noticeably. Excluding source folders in Windows Security is the standard fix and is worth doing deliberately rather than casually.
• Path length. Deep repositories hit the 260 character limit, exactly as node_modules does.
• Case insensitivity. A repository with two files differing only in case will misbehave on Windows, which is a correctness problem rather than a space one.

The cheapest gigabytes

For a repository that exists on a remote, the local clone is disposable. Check with git remote -v, then delete the folder and clone again when you need it. That is the fastest reclaim on any development machine and the one people forget.