# Auditing Local Repos for Corporate Remotes, Hardcoded Credentials, and Stale Configs Before Going Public

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:

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

#### What to Look For:

- Enterprise domain emails (e.g., [`user@company.com`](mailto: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

```plaintext
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`](mailto: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>