Stop Polluting Your .zshrc! Here’s How to Organize Your Shell Exports Like a Pro

Your .zshrc file doesn’t have to be a dumping ground for every environment variable you’ve ever set. I like the ability to commit and version control my configuration so that every new workstation, everything is already configured from the get go. You can see my configuration here: https://github.com/pgaijin66/dotfiles

Why This Matters

Look, we’ve all been there, you’re working on three different projects, switching between your personal laptop, work machine, and that random cloud instance you spun up for testing. Each time you have to remember which aliases you like, where you put that custom function for Docker cleanup, or how you configured your prompt. It’s annoying and wastes time that could be spent on actual work.

The beauty of treating your shell config as code is that you literally just clone your dotfiles repo and run a setup script. Boom !!! you’re back to feeling at home in any terminal. No more “wait, how did I set up my Git aliases again?” moments.

The Secret Problem

But here’s where it gets tricky. Over months of tweaking your config, you inevitably start adding API keys, database URLs, or tokens directly into your shell files. Maybe you needed that GitHub token for a quick script, or you hardcoded an AWS key for testing. Fast forward six months, and you’ve completely forgotten these secrets are lurking in your supposedly “safe” dotfiles repo.

I’ve seen people accidentally expose production database credentials this way, and it’s not fun explaining that to your security team. The worst part? These secrets often get buried in the middle of hundreds of lines of configuration, making them nearly impossible to spot during a quick review before pushing to GitHub.

A Better Approach

The solution is surprisingly simple, separate your public config from your private secrets. Your main .zshrc becomes a clean, shareable file that loads additional configuration from dedicated locations. Think of it like having a public face and a private diary.

Set up a structure where your version-controlled dotfiles handle all the safe stuff, aliases, functions, path modifications, and general environment setup. Then create separate files for anything sensitive that live only on each machine locally. Your .zshrc can try to source these private files if they exist, but gracefully continue if they don't.

This way, you get the best of both worlds: your productivity-boosting configuration follows you everywhere, but your secrets stay exactly where they should , locked away on individual machines and never touching version control. Plus, onboarding new team members becomes a breeze since they can use your public dotfiles without accidentally inheriting your personal API keys.

Trust me, future you will thank present you for taking the extra five minutes to set this up properly. It’s one of those small investments that pays dividends every single time you touch a new terminal.

I moved all my exports to ~/.config/exports/ and organized them by purpose:

~/.config/exports/
├── dev       # Development tools (NODE_ENV, API keys)
├── main      # Core system exports
├── paths     # PATH modifications
├── secrets   # Sensitive variables
└── tools     # Tool-specific configs

Once you do this, reference these exports in your bashrc or zshrc file

export EXPORTS_DIR="$HOME/.config/exports"

that’s it. Now you can manage your exports properly and do not have to worry about them committing to git.

Bonus Tips:

• Bonus: Use .gitignore for the secrets file
• Bonus++. Use global gitignore . People don’t know this, but it will make your life so much better.

# Create or edit your global gitignore
vim ~/.gitignore_global
 
# Add these inside

# Shell export files
.config/exports/secrets
.config/exports/dev
.config/exports/main
.config/exports/paths
.config/exports/tools

# Or ignore the entire exports directory
.config/exports/

# Alternative: ignore all export files but allow tracking specific ones
.config/exports/*
!.config/exports/main
!.config/exports/paths

• Version control the others for dotfile portability
• Add validation to catch typos before they break things

Your future self will thank you when you can actually find that one API key you set 6 months ago instead of grep-ing through a 1000-line .zshrc file.