Managing Multiple Git Identities on a Single Machine

I recently picked up a Nucbox K6 - partly for building Windows and Linux binaries, partly because I wanted a machine where I could finally play some Windows games without feeling guilty. But mostly for the builds.

Around the same time, I created a new GitHub organization and account for a new company project. This immediately created a problem I’ve dealt with before but never properly documented: managing two separate Git identities on the same machine.

The new account exists specifically to keep my personal identity separate from the company work. But this means I need Git to automatically use the right email, username, and credentials depending on which project I’m working on.

This is that documentation. It’s Sunday afternoon, and I’m going to walk through exactly what I did and what I learned - including why this was way easier on Windows than it was on macOS or Linux.

The Problem

When you work with multiple Git identities, you need to manage:

  1. User information - Different name and email per identity
  2. Authentication - Different credentials for different accounts
  3. Consistency - Making sure commits always use the right identity

The naive approach is setting git config user.name and git config user.email in each repository. This works until you:

  • Forget to set it in a new repo
  • Clone a repo and immediately commit with the wrong identity
  • Spend mental energy remembering which identity you should be using

I’ve done this wrong enough times that I wanted it automated. Set it once per directory, forget about it, move on with life.

My Setup Preferences

Before diving into Git configuration, here’s my environment setup:

I like splitting my machines into two partitions - one for the OS, one for data I don’t want to lose during OS reinstalls. On Windows, that’s the D: drive. On systems with better user support, it’s in my home directory.

I create a Code folder at the root of this partition. All my Git repositories live here in separate directories.

For this new project, I created D:\Code\CompanyProjects - everything under this directory needs to use the organization’s GitHub account credentials.

The Solution: Conditional Git Includes

Git has a feature called “conditional includes” that lets you load different configuration files based on the repository path. This is perfect for our use case.

Here’s what we’re setting up:

  • Global config - Default personal identity
  • Conditional config - Organization identity for specific directory path
  • Credential management - Separate PAT (Personal Access Token) storage

Why HTTPS + PAT Instead of SSH?

Most guides recommend SSH keys for multiple Git identities, and they’re not wrong - SSH is elegant and secure. But most people click the default “Clone” button on GitHub, which gives them HTTPS URLs.

HTTPS with Personal Access Tokens is what the majority of developers actually use, so that’s what we’re documenting here. It’s also simpler for credential management on Windows with Git Credential Manager.

Step 1: Check Your Starting Point

First, let’s see what we’re working with:

git --version
git config --global --list

On my fresh Nucbox K6:

git version 2.51.0.windows.1

[email protected]
user.name=Personal Name
core.autocrlf=true
core.eol=lf
init.defaultbranch=main
pull.rebase=true

Already had basic personal config set up. Good starting point.

Step 2: Verify Git Credential Manager

Windows Git installations typically include Git Credential Manager (GCM), which is vastly superior to the older credential helpers:

git-credential-manager --version

2.6.1+786ab03440ddc82e807a97c0e540f5247e44cec6

Perfect. GCM is installed and ready. This is where Windows has a significant advantage over macOS and Linux (more on that later).

Step 3: Create Organization-Specific Config

Create a separate Git config file for the organization identity:

File: ~/.gitconfig-company

[user]
	email = [email protected]
	name = work-username

[credential]
	# Use Git Credential Manager for storing PAT tokens
	helper = manager-core
	# Store credentials separately for this identity
	useHttpPath = true

The useHttpPath = true setting is crucial - it tells GCM to store credentials per-repository-path, not just per-domain. This allows different credentials for different GitHub organizations.

Step 4: Add Conditional Include to Global Config

Edit your main ~/.gitconfig to add the conditional include:

File: ~/.gitconfig

[user]
	email = [email protected]
	name = Personal Name

[core]
	autocrlf = true
	eol = lf

[init]
	defaultBranch = main

[pull]
	rebase = true

# Conditional include for company projects
[includeIf "gitdir:D:/Code/CompanyProjects/"]
	path = ~/.gitconfig-company

[credential]
	helper = manager-core

The magic line is:

[includeIf "gitdir:D:/Code/CompanyProjects/"]
	path = ~/.gitconfig-company

This tells Git: “If you’re inside a Git repository under D:/Code/CompanyProjects/, load ~/.gitconfig-company and override any conflicting settings.”

Important: The gitdir: condition only activates inside Git repositories, not just any directory under that path.

Step 5: Verify the Configuration

Test that the conditional config works:

# Personal repo - should show personal email
cd D:/Code/PersonalProjects/some-repo
git config user.email
# Output: [email protected]

# Organization directory - initialize a test repo
cd D:/Code/CompanyProjects
git init test-repo
cd test-repo

# Should show organization email
git config user.email
# Output: [email protected]

git config user.name
# Output: work-username

Perfect! The identity switches automatically based on directory path.

Why This Matters: The “Forgot to Configure” Problem

This is the real value of path-based configuration. I will forget to set the right Git identity in a new repository. I’ve done it dozens of times.

With this setup:

  • One-time configuration per directory path
  • Automatic identity switching for all repos under that path
  • No mental overhead remembering which identity to use
  • No manual git config commands for every new repository

While setting this up, I initially set the wrong email in the config file. Caught it immediately because I tested. If I had to set this per-repository, I’d probably be several repos deep before noticing the mistake.

Step 6: GitHub PAT Setup

Before cloning or pushing to the organization repository, you need a Personal Access Token.

Browser Profile Isolation

For the new organization account, I created a separate browser profile. This keeps the GitHub sessions isolated and prevents accidentally working in the wrong account.

Steps I took (useful for anyone doing similar setup):

  1. Create new browser profile - Completely separate session
  2. Install password manager extension (I use 1Password) - Critical for managing the new account’s credentials
  3. Log into GitHub with the organization account

Seriously, use a password manager. My organization account has a 20+ character randomly generated password and 2FA enabled. I have no idea what the password actually is, and that’s exactly how it should be.

Generating the PAT

In GitHub (logged in as the organization account):

  1. Settings → Developer settings → Personal access tokens → Tokens (classic)

  2. Generate new token (classic)

  3. Name it descriptively - “Nucbox K6 - Development”

  4. Select scopes based on your needs:

    • repo - Full repository access (required for private repos)
    • workflow - Modify GitHub Actions workflows (needed for CI/CD work)
    • write:packages - Upload packages (relevant for builder machines)

  5. Generate and copy the token

Important: You only see the token once. Don’t close the browser tab until you’ve tested it successfully.

Step 7: Clone and Test

Now clone a repository from the organization:

cd D:/Code/CompanyProjects
git clone https://github.com/company-org/test-repo.git

Git Credential Manager will prompt for authentication:

  • Username: Your GitHub username for the organization
  • Password: The PAT token (not your actual password!)

GCM stores these credentials in Windows Credential Manager. You’ll only need to enter them once per machine.

Make a Test Commit 

cd test-repo
echo "# Testing multi-identity Git setup" > test.txt
git add test.txt
git commit -m "Test commit from new machine"
git push

Check the commit:

git log

commit a1b2c3d4e5f6... (HEAD -> main, origin/main)
Author: work-username <[email protected]>
Date:   Sun Oct 12 13:06:21 2025 +0200

    Test commit from new machine

Perfect identity! The commit shows the correct author name and email automatically.

Verify Personal Repos Still Work 

cd D:/Code/PersonalProjects/some-repo
git pull

This worked without prompting for credentials - it used the existing personal account credentials stored separately in GCM.

Bonus: Global Gitignore

While we’re configuring Git, let’s set up a global gitignore for patterns that should never be committed in any project.

File: ~/.gitignore_global

# Global gitignore patterns

# Temporary and experimental directories
.tmp/
.tmp-*/
tmp-*/

# AI assistant instruction files (outdated docs that AI rarely follows anyway)
Claude.md
claude.md
CLAUDE.md
Cursor.md
cursor.md
.cursorrules
.cursor/
ChatGPT.md
chatgpt.md
AI-Instructions.md
ai-instructions.md

# Personal notes and logs
*.local.md
.notes/
.logs/

# OS generated files
.DS_Store
.DS_Store?
._*
.Spotlight-V100
.Trashes
ehthumbs.db
Thumbs.db
Desktop.ini

# IDE specific (personal preferences)
.vscode/settings.json
.idea/workspace.xml
.idea/tasks.xml

Enable it:

git config --global core.excludesfile ~/.gitignore_global

Why Ignore AI Assistant Instruction Files?

AI assistant instruction files (like Claude.md, .cursorrules, etc.) are like documentation - everyone intends to keep them updated, and nobody actually does.

More practically, I’ve yet to see an AI assistant consistently follow instructions from these files. Tell it “don’t use non-printable characters” - it uses them anyway. Tell it “run tests with make test” - it writes inline Python test code instead.

These files end up being noise in the repository. If you need instructions for AI assistants, keep them in your personal notes, not in version control.

The .tmp Directory Pattern

I like having a .tmp directory in projects for:

  • Experimental code that isn’t ready to commit
  • Personal notes about the project
  • Log files I want to keep around temporarily
  • Test data that shouldn’t be in the repo

Global gitignore handles this automatically for every project.

Platform Comparison: Wait, Windows Actually Works?

I’m a notorious anti-Windows person. If I didn’t need to build native Windows binaries, I would have installed Linux or Proxmox on this machine instead. So you can imagine my surprise when this setup went remarkably smoothly on Windows.

On macOS and Linux - platforms I actually prefer - I’ve fought with this problem multiple times.

macOS: The credential-osxkeychain Problem

macOS uses credential-osxkeychain as the default credential helper. It stores credentials in the system keychain, which sounds great until you need multiple identities.

The problem: credential-osxkeychain only supports one identity per domain. When you have multiple GitHub accounts, it doesn’t differentiate between them properly. You end up in authentication hell where Git uses the wrong credentials or prompts repeatedly.

The solution on macOS is typically:

  1. Install Git Credential Manager (separate install, not included by default)
  2. Or switch to SSH keys with per-directory SSH config
  3. Or use credential helper configurations that are more complex than the Windows setup

Linux: The Azure DevOps + GitHub Combination

On my work machine (Ubuntu VM), we use Azure DevOps for company code. I also wanted to manage personal GitHub projects on the same machine.

Azure DevOps has its own authentication quirks, and combining it with GitHub on Linux required:

  1. Custom credential helper configuration
  2. Careful separation of credential storage
  3. More manual configuration than I’d like to remember

I honestly don’t recall the exact issue I fought with on Linux - I just remember it taking way longer than it should have.

Windows: Git Credential Manager FTW

Git for Windows includes Git Credential Manager by default. GCM has native support for:

  • Multiple accounts per domain - GitHub personal + organization accounts work seamlessly
  • Multiple platforms - GitHub, Azure DevOps, GitLab, Bitbucket all work
  • Windows Credential Manager integration - Secure storage using OS-native mechanisms
  • Smart credential selection - The useHttpPath setting handles per-path credentials correctly

The entire setup took maybe 10 minutes, including writing this documentation. That’s a huge improvement over the macOS and Linux experiences.

Summary: The Complete Configuration

Here’s everything we set up:

~/.gitconfig - Global configuration with conditional include:

[user]
	email = [email protected]
	name = Personal Name

[core]
	autocrlf = true
	eol = lf
	excludesfile = ~/.gitignore_global

[init]
	defaultBranch = main

[pull]
	rebase = true

# Conditional include for organization projects
[includeIf "gitdir:D:/Code/CompanyProjects/"]
	path = ~/.gitconfig-company

[credential]
	helper = manager-core

~/.gitconfig-company - Organization-specific configuration:

[user]
	email = [email protected]
	name = work-username

[credential]
	helper = manager-core
	useHttpPath = true

~/.gitignore_global - Global ignore patterns:

.tmp/
Claude.md
# ... (other patterns as needed)

What This Gives You

  1. Automatic identity switching - Git uses the right name and email based on directory path
  2. Separate credential storage - Each identity has its own stored credentials
  3. Zero mental overhead - Clone a repo, it just works with the right identity
  4. Clean global ignores - No more committing .tmp directories or AI instruction files

Lessons Learned

Set this up once, properly. I’ve worked around Git identity problems for years by manually setting config per repository. It’s tedious, error-prone, and completely unnecessary.

Windows actually got this right. I can’t believe I’m saying this, but Git Credential Manager on Windows just works. On platforms I actually prefer (macOS/Linux), you’re either installing it separately or dealing with more configuration than should be necessary.

Path-based configuration scales. As you add more organizations or identities, just add more conditional includes. The pattern is consistent and maintainable.

Document your setup. This blog post exists because I’ve solved this problem before and forgot the details. Now it’s documented. Sunday afternoon well spent.

Conclusion

Managing multiple Git identities doesn’t have to be complicated. Git’s conditional includes combined with a good credential manager (which Windows provides by default) make this a 10-minute setup that just works.

If you’re on macOS or Linux and fighting with credential management, consider installing Git Credential Manager - it’ll save you hours of frustration.

Now I can get back to actually building things instead of fighting with Git configuration. Which was the entire point.

Setting up a new development machine is always an adventure. This was one of the smoother parts of the process.