Why My Disk is Always Full: The Hidden Cost of Company Git Repositories

Posted on August 21, 2025

Hey there!

So, there I was, working at this company, and I kept getting these annoying "Disk Almost Full" warnings on my laptop. I'd delete some old photos, clear the browser cache, maybe remove a few unused apps, and think I was good. But a few weeks later, there it was again - the dreaded warning.

I had no idea what was eating up all my space until I discovered the culprit: massive company git repositories with years of history.

The Mystery of the Disappearing Disk Space

The Problem

# My typical workflow at the company
git clone https://github.com/company/monorepo.git
cd monorepo
# Work on my feature
git checkout -b feature/my-new-feature
# Make changes, commit, push

I thought I was doing everything right. But what I didn't realize was that I was downloading years of company history, including:

• Every commit from the last 5+ years
• All the binary files, assets, and dependencies
• Multiple branches with their full histories
• Build artifacts and generated files

The Reality Check

One day, I decided to investigate what was actually taking up space:

# Check disk usage
df -h
# Output: /dev/disk1s1  256GB  245GB  11GB  96% /

# What's taking up space?
du -sh * | sort -hr | head -10
# Output:
# 45GB  monorepo
# 23GB  legacy-project
# 18GB  frontend-app
# 12GB  backend-service
# 8GB   mobile-app
# 6GB   documentation-site
# 4GB   test-suite
# 2GB   tools
# 1GB   scripts
# 500MB other-stuff

# Let's look at just the git directories
du -sh */\.git | sort -hr
# Output:
# 38GB  monorepo/.git
# 18GB  legacy-project/.git
# 12GB  frontend-app/.git
# 8GB   backend-service/.git
# 5GB   mobile-app/.git

Holy moly! Just the .git directories were taking up 81GB of my 256GB disk. That's almost a third of my entire storage!

What I Wish I Knew: Shallow Clones

The Better Approach

If I had known about shallow clones back then, my workflow would have been:

# Instead of full clone
git clone --depth 1 --single-branch --branch main https://github.com/company/monorepo.git
cd monorepo

# Check the difference
du -sh .git
# Output: ~200MB instead of 38GB

# Still get all the functionality I need
git status
git add .
git commit -m "Add new feature"
git push origin main

The Space Savings

Let me break down what I could have saved:

Repository	Full Clone	Shallow Clone	Savings
monorepo	38GB	200MB	37.8GB
legacy-project	18GB	150MB	17.85GB
frontend-app	12GB	100MB	11.9GB
backend-service	8GB	80MB	7.92GB
mobile-app	5GB	60MB	4.94GB
Total	81GB	590MB	80.41GB

That's 80GB of space I could have saved! My disk would have been at 165GB instead of 245GB.

Real Company Project Scenarios

Scenario 1: The Monorepo Nightmare

Many companies use monorepos that contain everything:

# This downloads the entire company history
git clone https://github.com/company/monorepo.git
# Contains: frontend, backend, mobile, docs, tools, legacy code, etc.
# Size: 45GB+ with full history

# Better approach
git clone --depth 1 --single-branch https://github.com/company/monorepo.git
# Size: ~200MB, still has everything you need to work

Scenario 2: The Legacy Project Trap

# Company has a 10-year-old project still in use
git clone https://github.com/company/legacy-system.git
# Downloads 10 years of commits, including old binary files
# Size: 23GB

# Shallow clone approach
git clone --depth 1 https://github.com/company/legacy-system.git
# Size: ~150MB, still works perfectly for current development

Scenario 3: The Multi-Branch Confusion

# Developer clones and checks out multiple branches
git clone https://github.com/company/project.git
git checkout develop
git checkout feature-branch
git checkout hotfix-branch
# Each branch brings its full history
# Total: 18GB

# Shallow clone with specific branch
git clone --depth 1 --single-branch --branch develop https://github.com/company/project.git
# Size: ~100MB, only what you need

The Company Workflow That Could Have Been

For New Features

# Clone only what you need
git clone --depth 1 --single-branch --branch develop https://github.com/company/project.git
cd project

# Create your feature branch
git checkout -b feature/your-new-feature

# Work normally
vim src/your-file.js
git add src/your-file.js
git commit -m "Add new feature"
git push origin feature/your-new-feature

# Create pull request from web interface

For Bug Fixes

# Quick fix workflow
git clone --depth 1 --single-branch --branch main https://github.com/company/project.git
cd project

# Fix the bug
vim src/buggy-file.js
git add src/buggy-file.js
git commit -m "Fix critical bug"
git push origin main

For Code Reviews

# Review specific branch
git clone --depth 1 --single-branch --branch feature/team-member-feature https://github.com/company/project.git
cd project

# Review the code
git log --oneline
git diff main..HEAD

# No need for full history to review current changes

The Hidden Benefits I Missed

1. Faster Cloning

# Full clone: 15-30 minutes
git clone https://github.com/company/monorepo.git

# Shallow clone: 30 seconds
git clone --depth 1 https://github.com/company/monorepo.git

2. Less Network Usage

• Full clone: Downloads 45GB over company network
• Shallow clone: Downloads 200MB
• Savings: 99.6% less bandwidth

3. Better Performance

# Full clone operations
git log --oneline  # Takes 5-10 seconds
git status         # Slower with large history
git checkout       # Slower with many branches

# Shallow clone operations
git log --oneline  # Instant
git status         # Fast
git checkout       # Fast

4. Easier Cleanup

# Remove old projects easily
rm -rf project-name  # 200MB instead of 18GB

What I Learned (The Hard Way)

1. Always Check Repository Size

# Before cloning, check what you're getting into
# Look at GitHub/GitLab for repository size
# Check with colleagues about typical clone sizes

2. Use Shallow Clones by Default

# Make shallow clones your default workflow
git clone --depth 1 --single-branch https://github.com/company/project.git

3. Clean Up Regularly

# Check disk usage periodically
df -h
du -sh */\.git | sort -hr

# Remove old projects
rm -rf old-project-name

4. Educate Your Team

Share these techniques with your colleagues:

• Create a team wiki page about shallow clones
• Add shallow clone instructions to onboarding docs
• Show the disk space savings to management

The Aftermath: My New Workflow

Now, whenever I start working on a company project:

# 1. Check available disk space
df -h

# 2. Clone with minimal depth
git clone --depth 1 --single-branch --branch main https://github.com/company/project.git
cd project

# 3. Verify I have what I need
git status
git log --oneline

# 4. Work normally
git checkout -b feature/my-feature
# Make changes, commit, push

# 5. Clean up when done
cd ..
rm -rf project  # Much faster cleanup

The Takeaway

If you're working at a company and your disk keeps filling up, chances are it's the git repositories. Here's what you can do:

1. Check your .git directories - they're probably huge
2. Use shallow clones for new projects
3. Clean up old repositories regularly
4. Share these techniques with your team
5. Consider this for company policy - shallow clones should be the default

The best part? You don't lose any functionality. You can still:

• Make commits and push changes
• Create branches and pull requests
• Review code and collaborate
• Access all current files and code

You just don't need the 10-year history of every commit to do your job effectively.

My disk is now much happier, and I wish I had known about shallow clones from day one at that company!

---

P.S. If you're dealing with this right now, check out my posts about working with git shallow clones and handling massive repositories for more detailed strategies.