Dotfiles: How Shell Aliases and Config Files Multiply Developer Output

Last year I got a new MacBook. Fresh out of the box, gorgeous screen. And then I spent six hours trying to remember how I'd configured my old machine. Which aliases did I have? What was that function I wrote for searching Git history? Where did I put my custom prompt?

Three weeks later, I found an old backup and discovered I'd recreated maybe 60% of my setup. The rest was gone.

If you've been coding for more than a couple years, you've had some version of this experience. Your shell configuration accumulates like sediment: a useful alias here, a PATH modification there, a function you copied from Stack Overflow in 2019 that you now rely on daily without quite remembering what it does.

Dotfiles management solves this. Not in some abstract "best practices" way, but in a very concrete "I can set up a new machine in 20 minutes instead of two days" way.

What Are Dotfiles?

Dotfiles are configuration files whose names start with a period. Unix systems hide these by default when you run ls, which is why your home directory looks clean even though it probably contains 50+ dotfiles right now.

The ones that matter most for shell productivity:

• .bashrc or .zshrc — your shell configuration, loaded every time you open a terminal
• .gitconfig — Git settings, aliases, and user identity
• .vimrc or .config/nvim/init.vim — editor configuration
• .tmux.conf — terminal multiplexer settings
• .ssh/config — SSH host aliases and connection settings

Run ls -la ~ on your machine right now. I just checked mine: 73 dotfiles and directories. Years of accumulated configuration, most of which I'd lose if my hard drive failed today.

The Compound Effect of Shell Aliases

A 2022 survey of developers on Hacker News found that the average respondent typed git status about 40 times per day. At roughly 3 seconds per command, that's 2 minutes daily on one Git command alone. Over a year, around 8 hours of your life typing "git status."

An alias like alias gs='git status' reduces those 11 keystrokes to 2. The time savings seem trivial in isolation. But aliases compound. Here are the ones I actually use daily, tracked over a week with shell history analysis:

# Git (roughly 45% of my alias usage)
alias gs='git status'
alias ga='git add'
alias gaa='git add --all'
alias gc='git commit -m'
alias gp='git push'
alias gl='git pull'
alias gd='git diff'
alias gco='git checkout'
alias gb='git branch'
alias glog='git log --oneline --graph --decorate -20'

# Navigation
alias ..='cd ..'
alias ...='cd ../..'
alias dev='cd ~/Developer'

# Listing
alias ll='ls -alF'

# Config shortcuts
alias zshrc='$EDITOR ~/.zshrc'
alias reload='source ~/.zshrc'

The reload alias is particularly useful while tweaking your configuration. Without it, you'd type source ~/.zshrc (or close and reopen your terminal) every time you make a change.

Functions for Complex Operations

Aliases work for simple command substitution. For anything with logic or arguments, use shell functions. These go in the same file:

# Create directory and cd into it
mkcd() {
  mkdir -p "$1" && cd "$1"
}

# Search in files with context
ff() {
  rg --color=always --line-number "$1" | less -R
}

# Commit with branch name prefix
gcb() {
  branch=$(git branch --show-current)
  git commit -m "[$branch] $1"
}

mkcd saves maybe 3 seconds per use, but I use it 10+ times a day when setting up project structures. Small savings, zero friction, no maintenance cost.

Three Ways to Manage Dotfiles with Git

The core idea is simple: track your config files in a Git repository so they're versioned, backed up, and portable across machines.

Method 1: Symlinks (Best for Beginners)

Create a dotfiles directory, move your configs there, then symlink them back to where the system expects them:

mkdir ~/dotfiles
mv ~/.zshrc ~/dotfiles/zshrc
mv ~/.gitconfig ~/dotfiles/gitconfig
ln -s ~/dotfiles/zshrc ~/.zshrc
ln -s ~/dotfiles/gitconfig ~/.gitconfig

cd ~/dotfiles
git init && git add . && git commit -m "Initial dotfiles"

• Pros: Simple to understand; files live in one place; works with any Git host
• Cons: Requires a setup script to recreate symlinks on new machines; some programs don't follow symlinks correctly

Method 2: Bare Git Repository

This method, documented by Atlassian, uses a bare Git repo with your home directory as the work tree. No symlinks needed:

git init --bare $HOME/.dotfiles
alias dotfiles='git --git-dir=$HOME/.dotfiles --work-tree=$HOME'
dotfiles config --local status.showUntrackedFiles no

dotfiles add ~/.zshrc ~/.gitconfig
dotfiles commit -m "Initial dotfiles"
dotfiles remote add origin git@github.com:username/dotfiles.git
dotfiles push -u origin main

• Pros: No symlinks; files stay in their original locations; clean tracking
• Cons: The dotfiles alias instead of git is non-obvious and easy to forget

Method 3: chezmoi (Best for Multiple Machines)

chezmoi handles templating (different configs for work vs. personal machines), secrets management, and setup scripts:

brew install chezmoi
chezmoi init
chezmoi add ~/.zshrc ~/.gitconfig
chezmoi edit ~/.zshrc   # edit managed files
chezmoi apply           # apply changes to home directory

• Pros: Templating for machine-specific configs; built-in secrets handling; automated setup scripts
• Cons: Another tool to learn; overkill for a single machine or simple setups

What Not to Version

The biggest mistake in public dotfiles repos: committed secrets. Never version any of these:

• API keys and tokens (GitHub, OpenAI, Stripe, etc.)
• Private SSH keys (~/.ssh/id_rsa — the ~/.ssh/config host-alias file is fine)
• AWS credentials (~/.aws/credentials)
• Database passwords or connection strings
• Anything from .env files

Instead, load secrets from a gitignored file:

# In .zshrc
[ -f ~/.secrets ] && source ~/.secrets

# In .gitignore
.secrets

Then ~/.secrets holds your actual values:

export GITHUB_TOKEN="ghp_xxxxxxxxxxxx"
export OPENAI_API_KEY="sk-..."

If you accidentally commit a secret, use BFG Repo Cleaner to scrub it from history — then rotate the credential immediately. Assume anything that touched a public Git repo is compromised.

A Practical Setup Checklist

The dotfiles topic on GitHub has thousands of examples. Browse a few for inspiration, but resist copying someone's elaborate setup. Start minimal and add what you actually use.

FAQ

Should I use Bash or Zsh?

If you're on macOS (which defaulted to Zsh starting with Catalina), use Zsh. If you're on Linux, either works. Oh My Zsh gives you a plugin ecosystem and sane defaults with almost no config. The aliases and functions in this article work in both shells.

How do I handle different configs for work vs. personal machines?

Simplest approach: a conditional based on hostname or a marker file:

if [ -f ~/.work_machine ]; then
  export GIT_AUTHOR_EMAIL="me@company.com"
else
  export GIT_AUTHOR_EMAIL="me@personal.com"
fi

For complex setups with 3+ machines, chezmoi's templating becomes worth learning.

How often should I commit my dotfiles?

Whenever you make a change you want to keep. I commit after adding any alias I've used more than twice. No schedule needed — the goal is backup and sync, not a pristine commit history.

What about VS Code or other GUI app settings?

VS Code stores its config in ~/.config/Code/User/settings.json (Linux) or ~/Library/Application Support/Code/User/settings.json (macOS). These are worth versioning if your editor config is substantial. Most other GUI app preferences change often and contain machine-specific paths, so I generally skip them.

For keyboard shortcut configuration across apps, our guide on Leader Key and Karabiner covers a complementary productivity layer on top of dotfiles.

Try It This Week

Pick three commands you type more than ten times daily. Create aliases for them. Drop them in a dotfiles repo. That's it for week one.

The goal isn't building the most elaborate setup on GitHub. The goal is to stop losing your accumulated configuration every time you switch machines. Start small, iterate when you feel friction, and in six months you'll wonder how you worked without it.