Recipe

Dotfiles strategy

Version-controlled shell configuration that follows you across every machine. One repo, zero drift, instant onboarding.

The problem

Every developer accumulates shell aliases, environment variables, editor settings, and tool configs. Without a strategy, these scatter across machines, rot over time, and cost hours during machine rebuilds or new-hire onboarding. A dotfiles repo is the industry-standard answer — but only if you structure it correctly.

The Meridian approach

1. Single repo, per-tool directories

One Git repository at ~/dotfiles. Inside:zsh/,git/,nvim/,tmux/. Each directory owns its config files. No monoliths.

2. Symlink installer script

A single install.sh at the repo root creates symlinks from $HOME into the repo. Idempotent, non-destructive, backs up existing files with a .bak suffix.

3. Machine-specific overrides

Source a ~/.localrc at the end of your shell rc file. That file stays out of version control and holds secrets, work-specific paths, and hostname conditionals. Clean separation of shared vs private config.

Why it matters

  • •New machine: clone, run install.sh, done in 90 seconds.
  • •Team consistency: shared aliases and tooling configs live in the repo.
  • •Audit trail: every config change is a commit with a message.

This recipe is part of the Meridian engineering playbook. For the full workstation bootstrap sequence, see Machine provisioning.