Running git status and seeing a clean working tree isn't enough. Leftover internal API endpoints, corporate SSH aliases, or commit author metadata can leak sensitive organizational details in seconds.

Here is a 4-step terminal audit protocol to verify your repository is completely sanitized before you make it public.

Step 1: Audit Historical Commit Headers for Email & Author Leaks

Even if your current .gitconfig uses a pseudonymous or personal identity, your past commits retain whatever email address was configured at the moment git commit was executed.

Run this single-line command to inspect the author name and email attached to every single commit across your branch history:

git log --all --format="%h | %an | %ae" | sort -u

What to Look For:

• Enterprise domain emails (e.g., user@company.com).
• Mismatched author names from early local prototyping.

Fixing author metadata retroactively: If you spot leaked enterprise emails in early commits, use git filter-repo (or git rebase -i for short commit histories) to rewrite the author metadata before pushing to a public remote.

Step 2: Inspect Stale Remotes and Upstream Pointers

It is common for private local builds to retain upstream pointers to corporate artifact registries, self-hosted GitLab instances, or staging mirrors.

Check all configured remote endpoints:

Bash

git remote -v

If internal or corporate remotes are still attached, remove them completely before linking your new public remote:

Remove unwanted corporate remote

git remote remove origin

Attach clean public remote

git remote add origin git@github.com:your-handle/your-public-repo.git

Step 3: Check .git/config for Hardcoded Tokens and Local Overrides

Local repository settings inside .git/config take precedence over global settings. Developers frequently drop temporary access tokens, internal proxy configurations, or custom SSH commands directly into .git/config during development.

Inspect the raw local configuration file directly:

Bash cat .git/config

Common Gotchas to Strip Out: Custom [core] sshCommand overrides pointing to workplace-issued SSH keys (e.g., ~/.ssh/id_ed25519_corp).

Embedded credentials inside HTTPS URLs (e.g., https://username:token@github.com/...).

Custom [http] or [https] proxy rules specific to internal corporate networks.

Step 4: Audit Unpushed Commits & Sensitive File Patterns

Before running your initial git push -u origin main, run a pre-flight diff check against your target branch to ensure no .env files, token logs, or build artifacts slipped through:

Bash

Verify unpushed local commit headers

git log origin/main..HEAD --format="%h | %an | %ae"

List all tracked files to ensure no sensitive files are accidentally tracked

git ls-files | grep -E "(.env|.pem|.key|config.json|id_rsa)"

If git ls-files returns any sensitive configuration files, untrack them immediately without deleting them from your disk:

Bash

git rm --cached .env echo ".env" >> .gitignore Free Verification Checksheet Want a systematic pre-flight audit template covering global vs. local precedence rules, multi-identity SSH setups, and commit verification commands?

Grab the free Git Multi-Identity & Local Security Checksheet on Gumroad:

👉 https://ecommercevb.gumroad.com/l/jmxecn

Need the full isolation toolkit? Check out the Side-Project IP Isolation Kit on Gumroad:

👉 https://ecommercevb.gumroad.com/l/side-project-ip-isolation-kit

Setting git config --global user.email globally is a recipe for mistakes. Relying on local git config overrides repo-by-repo fails the moment you git clone a new project and make a fast fix.

Here is how to set up automatic, directory-based Git identity switching using native Git conditional includes (includeIf).

Step 1: Structure Your Local Workspace

Organize your local repositories into clean top-level directories based on context:

~/Developer/
├── work/
│   └── company-api/
└── personal/
    └── side-hustle-app/

Step 2: Create Modular Git Configuration Files

Instead of putting identity data in your main ~/.gitconfig, create dedicated config files inside your home directory.

1. Create ~/.gitconfig-work: [user] name = Your Legal Name email = your.name@company.com

[core] sshCommand = ssh -i ~/.ssh/id_ed25519_work

2. Create ~/.gitconfig-personal: [user] name = Your Pseudonym Name email = 12345678+your-user@users.noreply.github.com

[core] sshCommand = ssh -i ~/.ssh/id_ed25519_personal

Step 3: Wire Up includeIf in Global ~/.gitconfig Open your global ~/.gitconfig.

Crucial Precedence Finding: Place the [includeIf] section at the very bottom of ~/.gitconfig (below any global [user] block). If placed above default [user] blocks, Git (tested on v2.43.0 Linux) silently overrides the conditional identity with the global fallback.

Base global defaults

[core] editor = code --wait autocrlf = input

Default fallback identity (optional)

[user] name = Default Dev email = dev@example.com

MUST BE AT THE BOTTOM: Conditional includes for Work & Personal

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

[includeIf "gitdir/i:~/Developer/personal/"] path = ~/.gitconfig-personal

Note: The gitdir/i: prefix makes directory path matching case-insensitive across macOS/Windows, and the trailing slash in ~/Developer/work/ ensures rules apply recursively.

Step 4: Verify Precedence & Audit Local Commits To verify that identity switching works before committing, test inside both folders:

Verify Work Identity

cd ~/Developer/work/company-api git config user.email

Output: your.name@company.com

Verify Personal Identity

cd ~/Developer/personal/side-hustle-app git config user.email

Output: 12345678+your-user@users.noreply.github.com

Before pushing to a remote repository, run this single-line bash command to audit unpushed local commit headers for accidental email exposure: git log origin/main..HEAD --format="%h | %an | %ae"

Free Verification Checksheet Want to double-check your global vs. local precedence rules, SSH host mapping, and pre-push commit history before your next release?

Grab the free Git Multi-Identity & Local Security Checksheet on Gumroad:

👉 https://ecommercevb.gumroad.com/l/jmxecn

A caveat first: a commit's name and email are labels you set. They are not proof of who wrote the code, and changing your config does not change commits you already made.

1. Organise your folders

~/Developer/
  work/
    company-api/
  personal/
    side-project/

2. Create one small config file per identity

~/.gitconfig-work:

[user]
    name = Your Work Name
    email = you@your-employer.example

~/.gitconfig-personal:

[user]
    name = Your Handle
    email = 12345678+your-username@users.noreply.github.com

Your noreply address is shown in your GitHub account's email settings.

3. Wire them up in ~/.gitconfig

[user]
    useConfigOnly = true

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

[includeIf "gitdir/i:~/Developer/personal/"]
    path = ~/.gitconfig-personal

Three details that matter, all from testing:

• End each path with /. With the slash, the rule matched a repository in a nested sub-folder. The same pattern without it did not match.
• Order matters. Git reads the file top to bottom and the last value wins. An includeIf placed above a default [user] block was overridden by that block. Put includes below it, or leave out the default.
• useConfigOnly = true with no default identity makes git refuse to commit in a repository outside both folders ("Author identity unknown"). That is a deliberate stop instead of a guess.

gitdir/i: ignores letter case, which helps on Windows and macOS. On Windows, write paths as ~/... or C:/Users/you/.... A Unix-style absolute path did not match in my Windows test, so check it on your own machine.

4. Check it before you commit

cd ~/Developer/work/company-api
git config user.email          # your work address

cd ~/Developer/personal/side-project
git config user.email          # your personal address
git config --show-origin user.email   # shows which file the value came from

5. Look at unpushed commits before you push

git log @{u}..HEAD --format='%h  author: %ae  committer: %ce  %s'

That lists commits not yet on the upstream branch with their author and committer emails. If you have no upstream set, use git log --format=... on its own to list the whole branch.

Free checksheet

I put the steps above, the config files, an SSH host-alias sample (not tested) and a small read-only script that checks unpushed commit emails into a free checksheet bundle: Git Multi-Identity Checksheet. I made it.

If you are also trying to understand what your employment contract says about side projects, I made a paid kit for that: Side-Project IP Isolation Kit. It contains no legal templates.

General information only. Not legal or employment advice. Read your own contract.

Forensic EDR & Network Telemetry: How Corporate IT Logs Side-Project IP (And How to Air-Gap Your Setup)

If you’re building a side project on nights and weekends while working full-time as a software engineer, you’ve probably justified your risk with a comforting assumption: “I’m writing code on my personal laptop, on my home Wi-Fi, using my personal GitHub account. Corporate legal will never know.”

It’s a clean mental model. Unfortunately, it’s entirely wrong.

During M&A due diligence, seed-round investor IP audits, or employment arbitrations, corporate legal doesn’t need to break into your home or seize your personal hardware to establish ownership. They rely on forensic telemetric artifacts that your everyday workflow leaks right under your nose.

The Git Identity Vector (.gitconfig & SSH Leakage)

Most engineers think switching between work and personal projects is as simple as running git config user.name inside a specific repo.

In practice, global configuration files leave massive blind spots:

1. Global Email Binding: If your global ~/.gitconfig defaults to your corporate email or references a corporate SSH key pair that handles fallback authentication for GitHub/GitLab, your personal commits can accidentally carry corporate identity signatures in the commit header metadata.

2. Shared SSH Agents: If your terminal daemon caches your corporate SSH key in memory while you’re pushing commits to a personal repository, audit logs can correlate key-signing events or socket paths.

To eliminate identity leakage, enforce path-based directory scoping in your global configuration:

# ~/.gitconfig
# Base global configuration (Defaults to personal identity)
[user]
    name = Your Personal Name
    email = your.personal@email.com

# Automatically switch identities based on directory path
[includeIf "gitdir:~/personal-projects/"]
    path = ~/.gitconfig-personal

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

If you're building on nights and weekends, your git identity, DNS requests, and file timestamps are creating a forensic trail right now — even on your personal machine. The full air-gap setup guide covers directory-scoped git configs, network isolation protocols, and the exact audit trail you need if HR ever asks questions. [$20 on Gumroad — link in bio.]

The Network Vector (Local Subnet & SWG Telemetry) This is the vector most senior devs completely overlook.

If your personal MacBook or Linux machine sits on the exact same residential home Wi-Fi gateway as your corporate work Mac running enterprise EDR (Endpoint Detection and Response) agents like CrowdStrike Falcon, Zscaler ZIA, or Netskope:

Control-Plane DNS Leakage: Your personal machine’s local DNS queries, outbound TLS handshakes to cloud providers (AWS, Vercel, Supabase, Neon), and API polling frequencies are visible across the local subnet gateway.

SWG Telemetry Corroboration: Secure Web Gateways often log local network neighbors or routing metadata. When corporate forensics cross-references timestamp spikes of outbound control-plane traffic from your home IP address alongside your employment timeline, a clear pattern of side-project development emerges.

The Contractual Vector (PIIA & Timestamp Convergence) Employment agreements usually contain broad PIIA (Proprietary Information and Inventions Agreement) clauses that claim ownership over anything touching your employer’s current or planned market domain.

When legal teams want to trigger a claim, they don’t guess — they look for timestamp convergence:

• An intense burst of coding activity on your personal GitHub repo at 11:30 PM on a Tuesday. • Corresponding corporate Slack/Teams activity or VPN session termination logs showing you logging off your work laptop at 11:15 PM. • Continuous overlap between your day-job mental domain and your night-time output.

How to Air-Gap Your Setup Properly To ensure your side project remains 100% legally and forensically unassailable, you need to enforce strict operational separation:

• Hardware Isolation: Zero network overlap. Never connect your personal side-project machine to the same physical network gateway or VPN profile as your corporate device. • Terminal Hardening: Audit your global Git configs, strip local SSH key caching bleed, and verify GPG key separation. • Telemetry Sanitization: Block local subnet enumeration and isolate your local DNS routing layers.

Everything above is the diagnostic. If you want the implementation — pre-configured .gitconfig templates, the 15-step network isolation checklist, and the scripted HR response playbook — it's packaged as a structured protocol covering US (CA § 2870), UK, Canada, and Australia.

Built for engineers who are serious about this, not just curious.

[Link in bio → $20, instant download.]

It’s a clean mental model. Unfortunately, it’s entirely wrong.

During M&A due diligence, seed-round investor IP audits, or employment arbitrations, corporate legal doesn’t need to break into your home or seize your personal hardware to establish ownership. They rely on forensic telemetric artifacts that your everyday workflow leaks right under your nose.

1. The Git Identity Vector (.gitconfig & SSH Leakage) Most engineers think switching between work and personal projects is as simple as running git config user.name inside a specific repo.

In practice, global configuration files leave massive blind spots:

Global Email Binding: If your global ~/.gitconfig defaults to your corporate email or references a corporate SSH key pair that handles fallback authentication for GitHub/GitLab, your personal commits can accidentally carry corporate identity signatures in the commit header metadata.

Shared SSH Agents: If your terminal daemon caches your corporate SSH key in memory while you're pushing commits to a personal repository, audit logs can correlate key-signing events or socket paths.

1. The Network Vector (Local Subnet & SWG Telemetry) This is the vector most senior devs completely overlook.

If your personal MacBook or Linux machine sits on the exact same residential home Wi-Fi gateway as your corporate work Mac running enterprise EDR (Endpoint Detection and Response) agents like CrowdStrike Falcon, Zscaler ZIA, or Netskope:

Control-Plane DNS Leakage: Your personal machine's local DNS queries, outbound TLS handshakes to cloud providers (AWS, Vercel, Supabase, Neon), and API polling frequencies are visible across the local subnet gateway.

SWG Telemetry Corroboration: Secure Web Gateways often log local network neighbors or routing metadata. When corporate forensics cross-references timestamp spikes of outbound control-plane traffic from your home IP address alongside your employment timeline, a clear pattern of side-project development emerges.

1. The Contractual Vector (PIIA & Timestamp Convergence) Employment agreements usually contain broad PIIA (Proprietary Information and Inventions Agreement) clauses that claim ownership over anything touching your employer’s current or planned market domain.

When legal teams want to trigger a claim, they don’t guess—they look for timestamp convergence:

An intense burst of coding activity on your personal GitHub repo at 11:30 PM on a Tuesday.

Corresponding corporate Slack/Teams activity or VPN session termination logs showing you logging off your work laptop at 11:15 PM.

Continuous overlap between your day-job mental domain and your night-time output.

How to Air-Gap Your Setup Properly To ensure your side project remains 100% legally and forensically unassailable, you need to enforce strict operational separation:

Hardware Isolation: Zero network overlap. Never connect your personal side-project machine to the same physical network gateway or VPN profile as your corporate device.

Terminal Hardening: Audit your global Git configs, strip local SSH key caching bleed, and verify GPG key separation.

Telemetry Sanitization: Block local subnet enumeration and isolate your local DNS routing layers.

Want the Complete 15-Step Playbook? If you want a granular, engineering-first checklist to completely air-gap your infrastructure, secure your Git telemetry, and eliminate corporate legal exposure before your public launch, check out the complete guide:

👉 Get The Corporate IP & Infrastructure Shield on Gumroad (Complete 15-step forensic EDR, network isolation, and PIIA compliance playbook for engineers)