How I configure my Git identities

Original Article ↗ Hacker News Discussion ↗

Managing multiple Git and SSH identities on the same machine—such as separate work, personal, and client accounts—turns out to be more flexible than many realize, thanks to features like `includeIf` and `hasconfig:remote` in `.gitconfig` and careful use of SSH config or aliases. Commenters compare strategies ranging from automatic, remote-based config selection to simple per-repo commands and even dedicated VMs or machines for strict separation, weighing convenience against security, privacy, and corporate compliance requirements. The overall consensus is that separate keys and identities are often necessary (especially with GitHub/GitLab policies and privacy concerns), but the ideal setup depends heavily on workflow, tooling, and employer rules.

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.