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.
-
Create a boundary.
First, isolate your work repositories. Keep them all inside a dedicated directory, like~/work/or~/onix/. -
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=yesI 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. -
Wire it to the global state.
Open your main~/.gitconfigfile. Add the directive that tells Git to watch your work directory.[includeIf "gitdir:~/work/"] path = ~/.gitconfig-workAny 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.
-
Install the infrastructure.
You likely already use Homebrew, so just runbrew install direnv. Hook it into your shell by addingeval "$(direnv hook zsh)"to your~/.zshrcfile. -
Extract your access token.
Go to your work GitHub account settings and generate a classic Personal Access Token. You probably only need therepoandread:orgscopes. Copy that token. -
Create the environment trap.
Go into your designated work directory. Create a file named.envrcand export the token.cd ~/work/ echo 'export GH_TOKEN="ghp_your_secure_token_here"' > .envrc direnv allowWhen you enter that folder,
direnvinjects the token into your active session. The GitHub CLI prioritises theGH_TOKENenvironment variable over whatever account is saved in your keychain. When you leave the folder,direnvunloads 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.