OneDrive vs Local Drive for Git Repos: The Definitive Answer (With 3 TB OneDrive and 150 GB Local)

You open your laptop, check your C: drive, and see 150 GB of total local storage — maybe 30 to 50 GB already used by Windows, your browsers, and installed software. Meanwhile, your company-issued OneDrive account shows 3 TB of available cloud storage, nearly untouched. The obvious thought arrives: why not just clone all my GitHub repositories into OneDrive and let it handle the backup and sync?

It seems logical. OneDrive already syncs your Word documents, your photos, and your PDF notes without a problem. Why should code be any different?

The answer is nuanced, technical, and important enough to get right — because choosing the wrong approach will cost you hours of debugging corrupted repositories, sluggish build times, and mysterious Git errors that only disappear when you move the folder off OneDrive.

This post covers everything: what Git actually does on your filesystem, why cloud sync services break that model, how much space developer repos actually take, the Windows Dev Drive option, and exactly what workflow to use given the 150 GB local / 3 TB OneDrive constraint.

---

The Mental Model Most Developers Get Wrong

Most people treat Git as a simple file-syncing tool: write code, commit, push, done. Under this mental model, OneDrive syncing seems redundant but harmless.

The reality is different. Git is a content-addressable filesystem and database engine layered on top of your operating system's filesystem. Every commit, every branch, every tag, every merge, and every working-tree checkout involves a specific choreography of read-write-rename-lock operations on the .git directory.

When you run `git commit -m "fix: update config"`, Git:

1.  Computes SHA1/SHA256 hashes of changed files (hundreds of
    small read operations)
2.  Writes new blob objects to .git/objects/ (many small writes)
3.  Updates .git/index (the staging area — write + lock)
4.  Updates .git/refs/heads/<branch> (write + rename)
5.  Writes the commit object (write)
6.  Updates .git/COMMIT_EDITMSG (write)
7.  Updates .git/ORIG_HEAD (write, sometimes)
8.  Releases all locks (unlock)

Total: 20–200 filesystem operations in under a second.

OneDrive, meanwhile, runs a background file watcher. Every time a file is created, modified, or renamed, it queues that file for upload. If Git is in the middle of step 4 above when OneDrive starts uploading step 3's output, you now have a race condition between two programs both trying to manipulate the same files.

This is not a theoretical problem. It is the source of the most common and painful errors developers report when working in synced folders.

---

What Actually Goes Wrong: A Taxonomy of OneDrive + Git Failures

1. Repository Corruption — The Most Dangerous Failure

Git's .git/index file is a binary file that acts as the staging area. It maps each file in your working tree to its corresponding object hash. This file is written and rewritten on almost every Git operation: git add, git checkout, git reset, git stash, and more.

OneDrive can upload a partially-written index file as though it were complete. If you switch to another computer (or if the file gets sync-conflicted back), you end up with a corrupted index. The symptoms:

error: bad index file sha1 signature
fatal: index file corrupt

Recovering from this requires running git checkout HEAD to rebuild the index from the last commit — and losing any staged changes. In worst cases, the .git/objects/ pack files become corrupt, and the repository requires a complete git clone from scratch.

Microsoft itself acknowledges in its support documentation that Git repositories stored in OneDrive-synced folders are prone to this class of corruption.

2. Sync Conflict Files — Git Sees Them, Breaks on Them

When you have two machines both with OneDrive running (say, your work laptop and your home desktop both synced to the same OneDrive account), and both have the same repository folder open, OneDrive may detect a sync conflict. When it cannot reconcile which version of .git/index is authoritative, it creates a second file:

.git/index (copy of the original)
.git/index-ChiragDesktop-20260614.txt  ← OneDrive "conflict copy"

Git does not know what to do with this. It ignores it silently, or sometimes errors out. Your repository is now in an undefined state. Running git status may show everything as clean while actually having a corrupted staging area.

3. node_modules — OneDrive's Kryptonite

If you work with any JavaScript or TypeScript project, your repository will eventually contain a node_modules folder after running npm install. A typical React project's node_modules contains:

Files:   ~35,000 to 80,000 individual files
Depth:   Nested 10–15 directories deep
Size:    500 MB to 2.5 GB
Symlinks: Dozens to hundreds of symbolic links

OneDrive's sync client was designed for documents and photos, not for tens of thousands of small files in deeply nested directories. When it encounters node_modules, it:

• Spikes CPU usage to 40–100% trying to enumerate and queue 60,000 files.
• Creates sync pending backlogs that may take hours to resolve.
• Fails to correctly sync symlinks, leaving broken references.
• Slows every subsequent npm install to a crawl because the filesystem is under constant monitoring pressure.

The OneDrive tray icon shows "Syncing..." permanently. Your machine slows down. Builds become erratic. This is the single most-reported pain point for developers who accidentally put projects inside OneDrive.

4. File Lock Conflicts

Git uses lock files as a mutual exclusion mechanism. When Git writes to .git/index, it first creates .git/index.lock, writes the new content, then atomically renames .lock to overwrite the original. If anything interrupts this sequence — including OneDrive trying to upload .git/index.lock mid-write — Git cannot complete the operation and errors:

fatal: Unable to create '.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again.

You can delete the .lock file manually, but the root cause is the sync client interfering with Git's atomic file operations.

5. Path Length Violations on Windows

Windows NTFS has a historical MAX_PATH limit of 260 characters. Even with the long-path registry override (LongPathsEnabled = 1), OneDrive's sync engine can still fail silently on deeply nested paths inside node_modules. You will see files marked as "sync errors" in OneDrive's status panel, and the local files will be missing or incomplete.

---

The Performance Cost: Numbers That Matter

Even when OneDrive is not actively corrupting anything, it degrades performance for active development in measurable ways.

Benchmark: git status on a medium-sized project (~5,000 tracked files)

Local NTFS drive (no watcher):         ~0.05 seconds
Local NTFS drive (Defender scanning):  ~0.3 seconds
OneDrive-synced folder:                ~1.2–3.0 seconds
OneDrive-synced + node_modules:        ~8–25 seconds (scan + queue overhead)

Every git commit, git checkout, git pull, and git push incurs this overhead. Over a day of active development with 50–100 Git operations, you are losing 5–30 minutes of pure wait time — and significantly more if your machine bogs down from the sync queue.

The deeper issue is that OneDrive's file system filter driver (onedrive.exe and its kernel-level hooks) intercepts every filesystem event on the synced folder. It runs alongside Windows Defender's real-time protection, which also intercepts these events. You now have three filesystem interceptors competing: Git, OneDrive, and Defender — on the same files, at the same time.

---

How Much Space Do Git Repositories Actually Take?

Before deciding what to do with your 150 GB local drive, understand the actual storage picture:

Storage consumption per repository type:

Minimal HTML/CSS project (no deps):        2–20 MB
React / Next.js app (with node_modules):   500 MB – 2.5 GB
Python project (with .venv):               200 MB – 800 MB
Rust workspace (with target/ folder):      1 GB – 5 GB
Full-stack monorepo (all deps):            3 GB – 15 GB
Large codebase with Git LFS assets:        5 GB – 50 GB

Important distinction: The actual Git repository (the .git folder and your source files) is usually very small:

Typical .git folder size:     5 MB – 150 MB
Typical source files only:    1 MB – 50 MB

What makes repos "big":
  node_modules/   → 500 MB – 2.5 GB (NOT part of Git)
  .venv/          → 200 MB – 800 MB (NOT part of Git)
  target/         → 1 GB – 5 GB     (NOT part of Git, Rust)
  dist/ or build/ → 50 MB – 500 MB  (NOT part of Git, usually)

These large folders are local build artifacts and dependency caches. They are in .gitignore and are never pushed to GitHub. They are recreated on every machine with npm install or pip install -r requirements.txt.

This distinction is crucial for the storage strategy.

---

The Right Answer: Where to Store What

Given the 150 GB local / 3 TB OneDrive constraint, here is the correct mental model:

+──────────────────────────────────────────────────────────────+
│                   STORAGE RESPONSIBILITY MAP                  │
+──────────────────────────────────────────────────────────────+
│                                                               │
│  LOCAL DRIVE (150 GB):                                        │
│  ┌──────────────────────────────────────┐                     │
│  │  C:\Dev\                             │                     │
│  │  ├── project-alpha\                  │  ← Active repos     │
│  │  │   ├── .git\          (5–150 MB)   │  ← Git metadata     │
│  │  │   ├── src\           (1–50 MB)    │  ← Your code        │
│  │  │   └── node_modules\  (500 MB–2GB) │  ← Local only       │
│  │  └── project-beta\                   │                     │
│  └──────────────────────────────────────┘                     │
│                                                               │
│  GITHUB (Unlimited for public / 1 GB soft limit private):     │
│  ┌──────────────────────────────────────┐                     │
│  │  github.com/chirag127/project-alpha  │  ← Code history     │
│  │  github.com/chirag127/project-beta   │  ← Collaboration    │
│  └──────────────────────────────────────┘                     │
│                                                               │
│  ONEDRIVE (3 TB):                                             │
│  ┌──────────────────────────────────────┐                     │
│  │  Documents\, Notes\, PDFs\           │  ← Documents        │
│  │  Design-Assets\                      │  ← Large media      │
│  │  Archived-Repos\ (bare .git bundles) │  ← Cold storage     │
│  └──────────────────────────────────────┘                     │
│                                                               │
+──────────────────────────────────────────────────────────────+

Rule 1: Active Git Repositories Go on the Local Drive

Clone all repositories you actively work on to a local folder completely outside of OneDrive:

# Create a dedicated dev folder on local drive (NOT in OneDrive)
New-Item -ItemType Directory -Path "C:\Dev" -Force

# Clone into the local folder
git clone https://github.com/chirag127/my-project.git C:\Dev\my-project

# Verify it is NOT inside the OneDrive-synced path
# Bad path:  C:\Users\C5420321\OneDrive - SAP SE\projects\
# Good path: C:\Dev\my-project\

Your 150 GB local drive is more than sufficient for active repositories. The actual source code + Git metadata for most projects is 10–200 MB. Even with 20 active projects averaging 100 MB each, that is only 2 GB.

The large folders (node_modules, .venv, target/) can be regenerated at any time with a single command and should be considered ephemeral — they live locally, serve their purpose, and can be deleted and rebuilt whenever you need the space back.

Rule 2: GitHub IS Your Cloud Backup — Use It

The correct multi-machine synchronization workflow is the one Git was designed for:

Machine A (Work Laptop, C:\Dev\)      Machine B (Home Desktop, D:\Dev\)
         │                                       │
         │  git push origin main                 │  git pull origin main
         │                                       │
         └──────────────── GitHub ───────────────┘
                    (github.com/chirag127/repo)

When you finish work on your laptop:

git add -A
git commit -m "feat: implement user auth"
git push origin main

When you sit down at your home machine:

git pull origin main
npm install  # Rebuild node_modules locally

This is not a workaround. This is the canonical, intended design of distributed version control. GitHub provides unlimited public repository storage and is specifically engineered to handle Git's object model correctly — something OneDrive is not designed to do.

Rule 3: Use OneDrive for What It Is Good At

OneDrive excels at syncing documents, notes, design assets, and media files — things that change infrequently and do not involve rapid, atomic multi-file writes.

OneDrive is great for:
  ✅ Word documents, Excel spreadsheets
  ✅ PDF notes and research papers
  ✅ Design assets (PNGs, SVGs, PSDs — individual large files)
  ✅ Configuration backups (dotfiles archives)
  ✅ Video recordings of screencasts or tutorials
  ✅ Database exports (.sql dumps, .csv files)
  ✅ Non-code project documentation
  ✅ Git bundle archives of completed/archived projects

Your 3 TB of OneDrive is a massive asset for these use cases — and they will never fill it up by competing with Git's internal file operations.

---

Advanced: Archiving Completed Projects to OneDrive

For repositories you have finished working on but want to preserve, you can create a Git bundle — a single-file archive of the entire repository history — and store that in OneDrive:

# Create a complete Git bundle archive of a finished project
# A bundle includes ALL commits, branches, and tags in one file

cd C:\Dev\finished-project

git bundle create `
    "C:\Users\C5420321\OneDrive - SAP SE\GitArchives\finished-project.bundle" `
    --all

# Verify the bundle is valid
git bundle verify `
    "C:\Users\C5420321\OneDrive - SAP SE\GitArchives\finished-project.bundle"

# Later, to restore from the bundle on any machine:
git clone `
    "C:\Users\C5420321\OneDrive - SAP SE\GitArchives\finished-project.bundle" `
    C:\Dev\finished-project-restored

A .bundle file is a single, self-contained binary file. OneDrive syncs it reliably because it is a single file that rarely changes. This gives you the best of both worlds: Git history preserved in cloud storage, without exposing the live .git directory to sync interference.

---

The Windows Dev Drive: The Upgrade Worth Knowing

Windows 11 (build 23H2 and later) ships with Dev Drive — a special storage volume type formatted with ReFS (Resilient File System) and tuned specifically for developer workloads.

Standard NTFS Drive:               Dev Drive (ReFS):
─────────────────────────────────────────────────────
Microsoft Defender: synchronous    Microsoft Defender: asynchronous
                    scanning                           (Performance Mode)
File filter overhead: high         File filter overhead: minimal
git status (5K files): ~0.3s      git status (5K files): ~0.05s
npm install (150 packages): ~45s   npm install (150 packages): ~28s
Build time (large project): 100%   Build time (large project): 70–85%
Block cloning: not supported       Block cloning: supported (CoW)

How to set up Dev Drive on Windows 11:

Settings (Win + I)
→ System
→ Storage
→ Advanced storage settings
→ Disks & volumes
→ Create Dev Drive

Requirements:

• Windows 11 version 23H2 or later
• At least 50 GB of available unallocated space (or resize a partition)
• Administrator permissions

After creation, mark it as trusted to enable Defender Performance Mode:

# Check if your Dev Drive is trusted
fsutil devdrv query D:

# Trust the drive (replace D: with your Dev Drive letter)
fsutil devdrv trust D:

Important: If your 150 GB local drive is an NVMe SSD, creating a Dev Drive partition (even 50 GB) specifically for your repositories will yield measurably faster Git operations, npm installs, and build times. The remaining 100 GB is still available for Windows and applications.

Recommended partition layout with 150 GB local NVMe:

  C:\  (100 GB NTFS)  — Windows, apps, program files
  D:\  (50 GB ReFS)   — Dev Drive: all Git repositories

---

What About the --separate-git-dir Workaround?

Some developers suggest a hybrid approach: store your working files (source code) in OneDrive but keep the .git metadata directory on a local drive using --separate-git-dir:

# Initialize a project with .git directory separated to local drive
# while working files live in OneDrive

git init \
    --separate-git-dir="C:\Dev\gitdirs\project-alpha.git" \
    "C:\Users\C5420321\OneDrive - SAP SE\projects\project-alpha"

This creates a small .git file (not a folder) inside the OneDrive directory that contains a single line pointing to C:\Dev\gitdirs\project-alpha.git. OneDrive syncs this tiny pointer file safely. The actual Git database stays local.

Pros of --separate-git-dir:
  ✅ Source files (your .js, .ts, .py) are synced to OneDrive
  ✅ Git metadata stays on fast local drive — no corruption risk
  ✅ Can access source files from any device via OneDrive web

Cons of --separate-git-dir:
  ⚠️  node_modules still inside OneDrive → still causes CPU/sync thrash
  ⚠️  .env files (if not gitignored) still in OneDrive
  ⚠️  Build artifacts in OneDrive = massive sync overhead
  ⚠️  Complex setup — easy to misconfigure
  ⚠️  OneDrive conflict files in source tree will confuse Git
  ⚠️  Needs careful .gitignore: node_modules, dist, .venv must be excluded
  ⚠️  Not universally supported by all Git GUIs

Verdict on --separate-git-dir: It solves the corruption problem but not the performance problem. Unless you specifically need access to raw source files from another device without cloning (e.g., you need to read config files on your phone), the complexity is not justified. The cleaner solution is to keep everything local and use GitHub for cross-machine synchronization.

---

A Practical Script: How to Audit Your Current Situation

If you have been working with repositories inside OneDrive already, this script will identify them and give you a migration report:

#!/usr/bin/env pwsh
# Finds all Git repositories inside OneDrive-synced folders on Windows
# and reports their status + estimated safe storage savings

$oneDrivePath = $env:OneDrive
if (-not $oneDrivePath) {
    # Try OneDrive for Business path
    $oneDrivePath = $env:OneDriveCommercial
}

if (-not $oneDrivePath) {
    Write-Host "OneDrive path not found in environment variables." -ForegroundColor Red
    Write-Host "Check: `$env:OneDrive or `$env:OneDriveCommercial" -ForegroundColor Yellow
    exit 1
}

Write-Host "`n══════════════════════════════════════════" -ForegroundColor Cyan
Write-Host " GIT REPOS INSIDE ONEDRIVE — AUDIT REPORT" -ForegroundColor Cyan
Write-Host "══════════════════════════════════════════`n" -ForegroundColor Cyan
Write-Host "Scanning: $oneDrivePath`n" -ForegroundColor Yellow

$gitRepos = Get-ChildItem -Path $oneDrivePath `
    -Directory -Filter ".git" -Recurse `
    -ErrorAction SilentlyContinue |
    Select-Object -ExpandProperty Parent

if ($gitRepos.Count -eq 0) {
    Write-Host "✅ No Git repositories found inside OneDrive." -ForegroundColor Green
    exit 0
}

Write-Host "⚠️  Found $($gitRepos.Count) Git repository/repositories inside OneDrive:" `
    -ForegroundColor Yellow
Write-Host ""

foreach ($repo in $gitRepos) {
    # Get size of .git folder
    $gitDir = Join-Path $repo.FullName ".git"
    $gitSize = [math]::Round(
        (Get-ChildItem $gitDir -Recurse -Force -ErrorAction SilentlyContinue |
         Measure-Object -Property Length -Sum).Sum / 1MB, 1
    )

    # Get size of node_modules if present
    $nodeModules = Join-Path $repo.FullName "node_modules"
    $nodeSize = 0
    if (Test-Path $nodeModules) {
        $nodeSize = [math]::Round(
            (Get-ChildItem $nodeModules -Recurse -Force `
                -ErrorAction SilentlyContinue |
             Measure-Object -Property Length -Sum).Sum / 1GB, 2
        )
    }

    Write-Host "  📁 $($repo.FullName)" -ForegroundColor White
    Write-Host "     .git folder size:    $gitSize MB" -ForegroundColor Gray
    if ($nodeSize -gt 0) {
        Write-Host "     node_modules size:   $nodeSize GB ← SYNC HAZARD" `
            -ForegroundColor Red
    }
    Write-Host ""
}

Write-Host "──────────────────────────────────────────" -ForegroundColor DarkGray
Write-Host "RECOMMENDED ACTIONS:" -ForegroundColor Cyan
Write-Host ""
Write-Host "  1. Move each repository to C:\Dev\ (or a Dev Drive)" -ForegroundColor White
Write-Host "  2. Push all branches to GitHub first (safety net)" -ForegroundColor White
Write-Host "  3. Delete the OneDrive copy after migration" -ForegroundColor White
Write-Host "  4. Add OneDrive exclusion for node_modules:" -ForegroundColor White
Write-Host '     OneDrive Settings → Backup → "Don'"'"'t back up" folders' `
    -ForegroundColor Gray
Write-Host ""
Write-Host "══════════════════════════════════════════`n" -ForegroundColor Cyan

---

Migration Guide: Moving Repos Out of OneDrive Safely

If you currently have repositories inside OneDrive and want to migrate them to a proper local path, follow these steps exactly:

# ═══════════════════════════════════════════════════════════
# STEP 1: Ensure all changes are pushed to GitHub first
# ═══════════════════════════════════════════════════════════
cd "C:\Users\C5420321\OneDrive - SAP SE\projects\my-repo"

# Check for unpushed commits on ALL branches
git log --oneline --all --not --remotes
# If this outputs anything, push those branches first:
# git push --all origin

# Check for uncommitted changes
git status
# If dirty, commit or stash first

# ═══════════════════════════════════════════════════════════
# STEP 2: Create the local dev folder
# ═══════════════════════════════════════════════════════════
New-Item -ItemType Directory -Path "C:\Dev" -Force

# ═══════════════════════════════════════════════════════════
# STEP 3: Move the repository (robocopy preserves attributes)
# ═══════════════════════════════════════════════════════════
robocopy `
    "C:\Users\C5420321\OneDrive - SAP SE\projects\my-repo" `
    "C:\Dev\my-repo" `
    /E /COPYALL /R:3 /W:5

# ═══════════════════════════════════════════════════════════
# STEP 4: Verify the moved repository is intact
# ═══════════════════════════════════════════════════════════
cd C:\Dev\my-repo
git status          # Should show clean working tree
git log --oneline -5  # Should show recent commits
git remote -v       # Should show GitHub remote

# ═══════════════════════════════════════════════════════════
# STEP 5: Delete the OneDrive copy
# Only do this AFTER verifying the local copy works correctly
# ═══════════════════════════════════════════════════════════
Remove-Item -Recurse -Force `
    "C:\Users\C5420321\OneDrive - SAP SE\projects\my-repo"

Write-Host "Migration complete! Repository is now at C:\Dev\my-repo" `
    -ForegroundColor Green

---

Storage Management: Making 150 GB Work for Active Development

The concern about running out of local space is real but solvable with discipline. Here is how to keep your 150 GB drive spacious:

Delete node_modules from Inactive Projects

# Find all node_modules directories and their sizes
Get-ChildItem -Path "C:\Dev" -Directory -Filter "node_modules" `
    -Recurse -ErrorAction SilentlyContinue |
    ForEach-Object {
        $size = [math]::Round(
            (Get-ChildItem $_.FullName -Recurse -ErrorAction SilentlyContinue |
             Measure-Object -Property Length -Sum).Sum / 1GB, 2
        )
        [PSCustomObject]@{
            Path    = $_.FullName
            Size_GB = $size
        }
    } |
    Sort-Object Size_GB -Descending |
    Format-Table -AutoSize

# Delete node_modules from a project you are not actively working on:
Remove-Item -Recurse -Force "C:\Dev\old-project\node_modules"
# Restore it in seconds when you need it again:
# cd C:\Dev\old-project && npm install

Use npkill for Interactive Cleanup

# Install globally once
npm install -g npkill

# Run inside your dev folder — interactive UI shows size saved in real-time
cd C:\Dev
npx npkill
# Arrow keys to navigate, Space to delete

Use Shallow Clones for Read-Only Reference Repos

# Clone only the latest commit (no history) for repos you just want to read
git clone --depth 1 https://github.com/some-org/reference-repo.git
# Saves 80–95% of clone size for repos with long histories

Archive Completed Projects

# Bundle + delete for finished projects
# Creates a portable archive, then frees local space

function Archive-GitRepo {
    param(
        [string]$RepoPath,
        [string]$ArchiveDir = "C:\Users\C5420321\OneDrive - SAP SE\GitArchives"
    )

    $repoName = Split-Path $RepoPath -Leaf
    $bundlePath = Join-Path $ArchiveDir "$repoName.bundle"

    New-Item -ItemType Directory -Path $ArchiveDir -Force | Out-Null

    Push-Location $RepoPath
    git bundle create $bundlePath --all
    $valid = git bundle verify $bundlePath
    if ($LASTEXITCODE -eq 0) {
        Pop-Location
        Remove-Item -Recurse -Force $RepoPath
        Write-Host "✅ Archived to: $bundlePath" -ForegroundColor Green
        Write-Host "   Local copy deleted. Restore with:" -ForegroundColor Gray
        Write-Host "   git clone $bundlePath C:\Dev\$repoName" -ForegroundColor Gray
    } else {
        Pop-Location
        Write-Host "❌ Bundle verification failed. Local copy preserved." `
            -ForegroundColor Red
    }
}

# Usage:
Archive-GitRepo -RepoPath "C:\Dev\finished-2024-project"

---

The Decision Matrix: Your Situation at a Glance

┌─────────────────────────────────────────────────────────────┐
│              STORAGE DECISION MATRIX                         │
├─────────────────────────┬───────────────────────────────────┤
│  Scenario               │  Correct Storage Location         │
├─────────────────────────┼───────────────────────────────────┤
│  Active Git repo (code  │  Local drive (C:\Dev\ or Dev      │
│  you commit to daily)   │  Drive). NEVER in OneDrive.       │
├─────────────────────────┼───────────────────────────────────┤
│  node_modules / .venv / │  Local drive only. These are      │
│  target / dist /        │  build artifacts — regenerate      │
│  build/                 │  on demand. Delete when idle.     │
├─────────────────────────┼───────────────────────────────────┤
│  Code backup /          │  GitHub (push from local). Not    │
│  cross-machine sync     │  OneDrive. GitHub understands Git.│
├─────────────────────────┼───────────────────────────────────┤
│  Finished / archived    │  OneDrive, as a .bundle file.     │
│  project (no longer     │  Single file, syncs reliably,     │
│  active)                │  full history preserved.          │
├─────────────────────────┼───────────────────────────────────┤
│  Documents, PDFs,       │  OneDrive. This is its native     │
│  notes, design assets   │  use case. Works perfectly.       │
├─────────────────────────┼───────────────────────────────────┤
│  Large binary assets    │  OneDrive or Git LFS. Do NOT      │
│  (videos, PSDs, etc.)   │  store in regular Git objects.    │
├─────────────────────────┼───────────────────────────────────┤
│  Secrets / .env files   │  Locally only. NEVER in OneDrive  │
│                         │  or GitHub. Use a secrets manager.│
└─────────────────────────┴───────────────────────────────────┘

---

Summary: What You Should Actually Do

Given your specific situation — 150 GB local storage, 3 TB OneDrive — here is the concrete action plan:

Set up your local dev environment:

# Create your local repository root
New-Item -ItemType Directory -Path "C:\Dev" -Force

# Optional but recommended: create a Dev Drive partition
# Settings → System → Storage → Advanced storage settings
# → Disks & volumes → Create Dev Drive (50 GB)
# Then clone to D:\Dev instead of C:\Dev

Use GitHub as your cloud layer:

# All new projects: clone to local, push to GitHub
git clone https://github.com/chirag127/project.git C:\Dev\project

# Work locally, push regularly
git push origin main

Use OneDrive only for:

• Non-Git documents and media
• .bundle archives of completed projects
• Non-code notes, PDFs, and configuration backups

Manage local space proactively:

# Delete node_modules from projects you are not actively using
npx npkill   # Interactive cleanup tool

The 150 GB local drive is not a limitation — it is more than enough for active development. The real question was never "do I have enough space?" — it was "do I understand what goes where?" Now you do.

OneDrive and Git are not enemies. They just have entirely different jobs. Stop asking OneDrive to do Git's job, stop asking Git to rely on OneDrive for safety, and both tools will serve you well within their own domains.

---

Written by Chirag Singhal. Based on first-hand developer experience, Microsoft's own OneDrive documentation, GitHub community discussions, and engineering analysis of Git's internal filesystem model.