One Laptop, Five Clients: Separate Git Identities, SSH Keys and Secrets Per Client with includeIf

The first time you freelance for more than one client at once, Git gets awkward fast.

One client wants commits from your agency email. Another gave you an account in their GitHub organisation with their own domain address. A third uses GitLab. Your personal projects use your personal email. And somewhere along the way you push a commit to a client repo signed as "abid@personal-gmail", or try to push and get "Permission denied (publickey)" because SSH offered the wrong key.

None of this is dramatic, but it looks sloppy to clients and it wastes time. Worse, it's easy to let one client's credentials or .env file end up somewhere they don't belong.

Here's the setup I'd recommend to anyone working with several clients from one machine. It takes about twenty minutes, and after that the right identity is picked automatically based on which folder you're in.

The idea: one folder per client

Everything hangs off a predictable directory layout:

~/work/
  personal/
  clients/
    acme/
      website/
      api/
    northwind/
      shop/

Git can apply configuration based on where a repository lives on disk, using includeIf "gitdir:...". SSH can pick a key based on a host alias. Put the two together and the folder decides the identity.

Step 1: A base .gitconfig with conditional includes

Your global config holds defaults plus one include per client:

# ~/.gitconfig
[user]
    name = Abid Ali
    email = abid@personal.example
    useConfigOnly = true

[init]
    defaultBranch = main

[includeIf "gitdir:~/work/clients/acme/"]
    path = ~/.gitconfig.d/acme

[includeIf "gitdir:~/work/clients/northwind/"]
    path = ~/.gitconfig.d/northwind

Details that matter:

• The trailing slash is important. gitdir:~/work/clients/acme/ matches every repository under that folder. Without the slash, it would only match a repository whose .git directory is exactly that path.
• Later settings win. Includes are processed where they appear, so put them after the default [user] block.
• useConfigOnly = true stops Git from guessing an email from your hostname. If an identity is missing, Git refuses to commit instead of committing as abid@abids-laptop.local.
• On Windows or macOS with case-insensitive file systems, there's also gitdir/i: for a case-insensitive match.

Each client file is short:

# ~/.gitconfig.d/acme
[user]
    name = Abid Ali
    email = abid@acme-contractor.example

[core]
    sshCommand = ssh -i ~/.ssh/id_ed25519_acme -o IdentitiesOnly=yes

Check that it works from inside a client repo:

cd ~/work/clients/acme/website
git config user.email
# abid@acme-contractor.example

git config --show-origin --get user.email
# file:/home/abid/.gitconfig.d/acme   abid@acme-contractor.example

--show-origin is the fastest way to debug "why is Git using that email?"

Step 2: One SSH key per client account

If a client gives you a separate GitHub account (or you made one for them), each account needs its own SSH key, because GitHub identifies you by the key. Generate one per client:

ssh-keygen -t ed25519 -C "abid acme" -f ~/.ssh/id_ed25519_acme
ssh-keygen -t ed25519 -C "abid northwind" -f ~/.ssh/id_ed25519_northwind

Add each public key (.pub) to the matching account, and give each a passphrase. Your SSH agent or OS keychain means you won't type it often.

There are two ways to make Git use the right key.

Option A: core.sshCommand in the client's include (shown above). Repository URLs stay normal (git@github.com:acme/website.git), and the folder decides the key. IdentitiesOnly=yes matters: without it, SSH may offer every key loaded in your agent first, and GitHub accepts the first key that belongs to any account, which might be the wrong one.

Option B: host aliases in ~/.ssh/config:

# ~/.ssh/config
Host github-acme
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_acme
    IdentitiesOnly yes

Host github-northwind
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_northwind
    IdentitiesOnly yes

Then clone with the alias:

git clone git@github-acme:acme/website.git ~/work/clients/acme/website

Option B is more explicit and works outside Git too. Option A is easier to forget about, in a good way. I use A for repos and keep B around for tools that shell out to SSH directly.

Test the key before you need it:

ssh -T git@github-acme
# Hi abid-acme! You've successfully authenticated, but GitHub does not provide shell access.

The username in that reply tells you which account the key belongs to. If it's wrong, fix it now, not ten minutes before a deadline.

Step 3: Rewrite URLs automatically (optional)

If clients send you plain git@github.com:acme/... URLs and you use host aliases, you can rewrite them per folder:

# ~/.gitconfig.d/acme
[url "git@github-acme:acme/"]
    insteadOf = git@github.com:acme/

Now git clone git@github.com:acme/website.git inside the acme folder silently uses the right alias. One caveat: includeIf "gitdir:" is matched against a repository's location, and you can't always rely on it during the very first clone into a new folder. For that first clone, either use the alias directly or pass the key explicitly with git -c core.sshCommand="ssh -i ~/.ssh/id_ed25519_acme -o IdentitiesOnly=yes" clone ....

Step 4: Keep secrets per client, not global

Identity is half the problem. The other half is environment variables and API keys. A few habits:

• Never export client secrets in your shell profile. A global STRIPE_SECRET_KEY in ~/.bashrc will eventually get used in the wrong project.
• Use a per-folder loader like direnv. An .envrc in ~/work/clients/acme/ loads that client's variables when you cd in and unloads them when you leave:

# ~/work/clients/acme/.envrc
export AWS_PROFILE=acme
export VERCEL_ORG_ID=team_acme_example
dotenv_if_exists .env.local

Run direnv allow once per folder after reviewing the file.

• Ignore env files everywhere, not just per repo, with a global ignore file:

# ~/.gitconfig
[core]
    excludesFile = ~/.gitignore_global

# ~/.gitignore_global
.env
.env.*
!.env.example
.envrc
*.pem
.DS_Store

• Scan before you push. A pre-commit hook with a secret scanner such as gitleaks catches the API key you pasted "just for a minute". Even one shared hook across your client repos is better than nothing.

Step 5: Personal notes without polluting the client repo

Freelancers keep notes: TODOs, client quirks, local scripts. Don't commit them, and don't add your personal files to the client's .gitignore either. Each repository has a private ignore file that never gets committed:

echo "NOTES.md" >> .git/info/exclude
echo "scratch/" >> .git/info/exclude

Step 6: Offboarding

When a contract ends, clean up deliberately, and tell the client you did:

# Remove the key locally and from the account (or ask the client to remove the account)
rm ~/.ssh/id_ed25519_acme ~/.ssh/id_ed25519_acme.pub

# Remove the include and the folder once handover is confirmed
rm ~/.gitconfig.d/acme

Also revoke any personal access tokens you created for that client, sign out of their cloud consoles, and delete local copies of production data. Clients notice when a freelancer leaves the door locked behind them, and it's the kind of thing that turns into a good review and a repeat contract. The guide on what to do after you win an Upwork job covers the client-facing side of starting a contract well; this setup is the technical half of the same habit.

A quick sanity checklist

Before your first commit on a new client repo:

git config --show-origin user.email   # right email, from the right file?
ssh -T git@github.com                  # (or your alias) right account?
git log -1 --format='%an <%ae>'        # after committing: right author?

If you already pushed commits with the wrong email, don't rewrite shared history without asking. Tell the client, fix it going forward, and only rewrite if they ask for it.

Recap

• One folder per client, and includeIf "gitdir:.../" to pick the identity.
• One SSH key per client account, with IdentitiesOnly=yes.
• useConfigOnly = true so a missing identity fails loudly.
• Per-folder secrets with direnv, a global ignore for env files, and a secret scanner.
• Clean up keys, tokens and data when the contract ends.

It's boring infrastructure. That's the point: once it's in place, you stop thinking about it and clients only see clean, correctly attributed work.

Abid Ali is a web developer and freelancer in Pakistan. He writes beginner-friendly freelancing guides at Digital Dialogue.