How I configure my Git identities

Original Article ↗ Hacker News Discussion ↗

Git identity and SSH configuration

  • Many favor using ~/.ssh/config with per-host aliases and IdentityFile entries to manage multiple SSH keys, including for GitHub/GitLab orgs.
  • Others prefer Git-level control via core.sshCommand (possibly in included configs) to avoid touching SSH config and make per-repo identity self-contained.
  • includeIf is widely praised:
    • includeIf "gitdir:…" to split work vs personal based on directory trees.
    • includeIf "hasconfig:remote.*.url:…" (highlight of the article) to apply identities based on remote URLs and even work during clone.
  • Some use insteadOf URL rewriting (e.g., work:repo → full GitLab URL), but this can clash with includeIf and require rewriting existing remotes.
  • Order and case sensitivity of includeIf matter; “last one wins.” Not all Git clients (e.g., JGit) support includeIf.

Security, privacy, and keys

  • Reasons to use separate SSH/signing keys:
    • Privacy and unlinkability between accounts.
    • GitHub accounts cannot share SSH keys; enterprise vs public accounts may require distinct keys.
    • Limiting blast radius if a key or provider is compromised.
  • Some argue a single key per workstation is acceptable, especially if all keys live on the same machine anyway.
  • Others recommend hardware tokens (FIDO2/GPG/smartcard) or password managers acting as SSH agents to avoid on-disk keys.
  • For signing keys, some suggest revoking/deleting work signing keys after leaving a job to prevent impersonation; others question the practical benefit.

Work vs personal machines

  • Debate over mixing identities on one machine:
    • Pro separation: dedicated work hardware or OS user simplifies legal “purge all files” requirements, reduces IP leakage risk, and aids mental / security compartmentalization.
    • Counterpoints: risks and policies vary by employer; careful directory separation and contracts may suffice, and extra devices have costs.
  • Some employers prohibit personal work on company machines or vice versa; others are lax.

Tools and workflows

  • Several tools are shared for managing multiple SSH/Git identities (e.g., identity switchers, GitHub key managers, SSH “environment” managers).
  • Alternative workflows include:
    • Git aliases (git config-personal, git config-company) that write per-repo config, though some see this as duplication and error-prone.
    • Using local VMs or containers for compartmentalization.
    • NixOS/home-manager to declaratively generate Git configs.

Miscellaneous

  • Some note annoyance that Git/SSH config must be coordinated, and that certain setups may repeatedly prompt for key passwords.
  • A few comments highlight site aesthetics and the long delay between drafting and publishing the article.