Skip to content
Go back

Managing Dual GitHub Identities Like an Insider

Managing Dual GitHub Identities Like an Insider

The old rule of version control was strict. One machine meant one developer identity. Most of us started with a single global git configuration file. Today many engineers need more than one active identity. You might be contributing to an open source project in the morning and writing proprietary code in the afternoon.

The scariest thing for a platform engineering team is an employee pushing internal code from a personal pseudonymous GitHub account. It pollutes audit logs and creates compliance headaches. Relying on manual switching is likely to cause a slip‑up at the worst moment.

The smartest engineers I know do not trust memory for this. They automate identity management at the folder level. Below are the exact steps to configure both Git and the GitHub CLI to switch profiles automatically based on the current directory.

Part 1: The Native Git Solution

Git introduced conditional includes years ago. It is probably the best native tool for this job, yet many developers misuse it. The premise is simple: Git can load a specific configuration file only when you are inside a designated folder.

  1. Create a boundary.
    First, isolate your work repositories. Keep them all inside a dedicated directory, like ~/work/ or ~/onix/.

  2. Establish the localized identity.
    Create a specific configuration file for your professional identity. You might name it ~/.gitconfig-work. In this file, set your corporate name, email, and the exact SSH key you need.

    [user]
        name = Your Corporate Name
        email = [email protected]
    [core]
        sshCommand = ssh -i ~/.ssh/id_ed25519_work -o IdentitiesOnly=yes

    I recommend adding IdentitiesOnly=yes. I once spent three hours debugging a failed push only to realize my SSH agent was prioritising my personal key over my work key. That setting forces Git to use the exact key you specify.

  3. Wire it to the global state.
    Open your main ~/.gitconfig file. Add the directive that tells Git to watch your work directory.

    [includeIf "gitdir:~/work/"]
        path = ~/.gitconfig-work

    Any time your terminal is inside ~/work/ or its subdirectories, Git quietly adopts your professional persona.

Part 2: The GitHub CLI Anomaly

Git handles native code pushes beautifully. The GitHub CLI (gh) assumes you are one person with one global state stored in your macOS Keychain.

To manipulate the GitHub CLI, we have to manipulate the environment itself. The most elegant solution for this is a tool called direnv. It is an environment variable manager that hooks directly into your shell. When you change directories, it automatically loads or unloads specific variables in the background.

  1. Install the infrastructure.
    You likely already use Homebrew, so just run brew install direnv. Hook it into your shell by adding eval "$(direnv hook zsh)" to your ~/.zshrc file.

  2. Extract your access token.
    Go to your work GitHub account settings and generate a classic Personal Access Token. You probably only need the repo and read:org scopes. Copy that token.

  3. Create the environment trap.
    Go into your designated work directory. Create a file named .envrc and export the token.

    cd ~/work/
    echo 'export GH_TOKEN="ghp_your_secure_token_here"' > .envrc
    direnv allow

    When you enter that folder, direnv injects the token into your active session. The GitHub CLI prioritises the GH_TOKEN environment variable over whatever account is saved in your keychain. When you leave the folder, direnv unloads the token, and the CLI instantly reverts to your personal account.

    It is a silent, automated shift in identity. Better than manual login and logout, you simply change directories and get back to writing code.

I started using this setup on a side project last month. After a weekend of coding, I pushed a hot‑fix to the wrong repository. The mistake was caught early because the commit author was clearly marked as a personal account. Switching the folder fixed the problem in seconds.

  • This approach works on macOS and Linux.
  • It requires a one‑time setup of direnv.
  • Once configured, you can keep multiple GitHub accounts side by side without thinking about them.

Tags

Share this post on: