When converting an internal or side-project repository from a private workspace into an open-source public project, flipping the visibility switch on GitHub or GitLab is the easy part. The dangerous part is what sits hidden in your local commit history, untracked files, or environment configs.

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