DEV Community

Cover image for The Complete Guide to Working with Single Folders in Multi-Project GitHub Repositories
K-kibet
K-kibet

Posted on

The Complete Guide to Working with Single Folders in Multi-Project GitHub Repositories

A practical guide to cloning, modifying, and pushing changes to specific folders in monorepos without dealing with unrelated projects

Have you ever encountered a GitHub repository that contains multiple projects, but you only need to work on one specific folder? Maybe it's a company monorepo with dozens of projects, or an open-source repository with various examples and tools. Downloading the entire repository when you only care about one project feels inefficient and cumbersome.

In this comprehensive guide, I'll show you exactly how to work with single folders in multi-project repositories—from initial clone to final push—without the overhead of dealing with unrelated projects.

Understanding the Challenge

Many organizations use monorepos (single repositories containing multiple projects) for better code sharing, dependency management, and collaboration. However, as a developer, you might only need to work on one specific project within that repository.

The challenge is threefold:

  1. Cloning only the folder you need
  2. Making changes in isolation
  3. Pushing back changes without affecting other projects

Method 1: Sparse Checkout (Recommended Approach)

This is the most reliable method for working with single folders while maintaining full git functionality.

Step 1: Clone Only Your Target Folder

# Create a new directory for your work
mkdir my-project && cd my-project

# Initialize git repository
git init

# Add the remote repository
git remote add origin https://github.com/username/multi-project-repo.git

# Enable sparse checkout
git config core.sparseCheckout true

# Specify EXACTLY which folder you want
echo "project-a/*" > .git/info/sparse-checkout

# Fetch and checkout only your specified folder
git fetch --depth=1 origin main
git checkout origin/main
git switch -c main
Enter fullscreen mode Exit fullscreen mode

Step 2: Verify Your Setup

Check that you only have the files you need:

# List all tracked files - should only show your project folder
git ls-files

# Check current status
git status
Enter fullscreen mode Exit fullscreen mode

You should only see files from your target folder (e.g., project-a/).

Method 2: Quick Sparse Clone with Filter

For a more streamlined approach:

git clone --filter=blob:none --no-checkout https://github.com/username/multi-project-repo.git
cd multi-project-repo
git sparse-checkout init --cone
git sparse-checkout set project-a
git checkout main
Enter fullscreen mode Exit fullscreen mode

Making Changes in Isolation

Now you can work on your project without worrying about other folders:

# Navigate to your project
cd project-a

# Make your changes - edit files, add new ones, etc.
# The rest of the repository doesn't exist in your workspace

# Create new files
touch new-feature.js

# Edit existing files
echo "// New functionality" >> existing-file.js
Enter fullscreen mode Exit fullscreen mode

Pushing Changes Back to the Specific Folder

This is where many developers get nervous—but the process is straightforward.

Step 1: Stage Your Changes Carefully

# Check what will be committed
git status

# Add all changes in your project folder
git add .

# Verify only your project files are staged
git diff --staged --name-only
# Should only show files in project-a/
Enter fullscreen mode Exit fullscreen mode

Step 2: Commit with a Descriptive Message

git commit -m "project-a: Added new authentication features

- Implemented OAuth2 integration
- Added user session management
- Updated documentation"
Enter fullscreen mode Exit fullscreen mode

Using project-a: prefix in your commit message helps maintain clarity in the repository history.

Step 3: Pull Latest Changes and Handle Conflicts

Always pull before pushing to avoid conflicts:

git pull origin main
Enter fullscreen mode Exit fullscreen mode

If there are conflicts, they'll only occur in files within your project folder, since those are the only files you have.

Step 4: Push Your Changes

git push origin main
Enter fullscreen mode Exit fullscreen mode

Safety Checks and Best Practices

Pre-Push Verification Script

Create a script to ensure you're only modifying your intended folder:

#!/bin/bash
# safe-push.sh

PROJECT_DIR="project-a"  # Change this to your folder

echo "Running safety checks..."

# Check for files outside target directory
stray_files=$(git ls-files --cached | grep -v "^$PROJECT_DIR/" | grep -v "\.git")
if [ ! -z "$stray_files" ]; then
    echo "ERROR: Found files outside $PROJECT_DIR:"
    echo "$stray_files"
    echo "Aborting push."
    exit 1
fi

# Check for unstaged changes
if ! git diff --quiet; then
    echo "Warning: You have unstaged changes."
    read -p "Continue anyway? (y/N): " -n 1 -r
    echo
    if [[ ! $REPLY =~ ^[Yy]$ ]]; then
        exit 1
    fi
fi

echo "Safety checks passed. Proceeding with push..."
git pull origin main
git push origin main
Enter fullscreen mode Exit fullscreen mode

Handling Common Issues

Problem: "Updates were rejected because the remote contains work you do not have locally"

# This happens when others modified files in your project folder
git pull origin main --allow-unrelated-histories
# Resolve any conflicts, then push
git push origin main
Enter fullscreen mode Exit fullscreen mode

Problem: Accidentally staged files outside your project

# Unstage all files
git reset

# Only stage files in your project folder
git add project-a/
Enter fullscreen mode Exit fullscreen mode

Advanced Techniques

Working with Multiple Related Folders

If your project depends on shared utilities:

# Add additional folders to sparse checkout
echo "shared-libraries/" >> .git/info/sparse-checkout
echo "common-config/" >> .git/info/sparse-checkout
git checkout main
Enter fullscreen mode Exit fullscreen mode

Creating Feature Branches

# Create a feature branch
git checkout -b feature/new-authentication

# Make changes, commit, and push
git push origin feature/new-authentication

# Create PR on GitHub, then merge to main
Enter fullscreen mode Exit fullscreen mode

Why This Approach Works

  1. Sparse Checkout: Git only checks out the files you specify, but maintains awareness of the entire repository structure
  2. Smart Pushing: Git tracks what actually changed and only transmits those deltas
  3. Path-Based Operations: Most git operations are path-aware, so pushing only affects the files you modified

Real-World Example: Company Monorepo

Let's walk through a realistic scenario:

# Clone only the frontend project from company monorepo
mkdir company-frontend && cd company-frontend
git init
git remote add origin https://github.com/company/monorepo.git
git config core.sparseCheckout true
echo "apps/web-frontend/*" > .git/info/sparse-checkout
git fetch --depth=1 origin main
git checkout origin/main
git switch -c main

# Work on frontend changes
cd apps/web-frontend
# ... make changes ...

# Safely push back
git add .
git commit -m "apps/web-frontend: Updated responsive design"
git pull origin main
git push origin main
Enter fullscreen mode Exit fullscreen mode

Benefits of This Workflow

  • Reduced Download Size: Only get what you need
  • Faster Operations: No unnecessary file processing
  • Focused Development: No distractions from unrelated projects
  • Maintained Collaboration: Full compatibility with team workflows
  • Safety: Little risk of accidentally modifying other projects

Conclusion

Working with single folders in multi-project repositories doesn't require complex tools or risky procedures. With sparse checkout, you can efficiently collaborate on large monorepos while maintaining the focus and simplicity of working with a single project.

The key takeaways:

  1. Use sparse checkout to clone only what you need
  2. Always verify your changes before committing
  3. Pull before pushing to avoid conflicts
  4. Use descriptive commit messages

This approach gives you the best of both worlds: the collaboration benefits of monorepos with the focused workflow of single-project repositories.

Next time you face a massive repository, remember—you don't need to clone it all. Just take what you need and leave the rest.

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.