public-release-prep

Public Release Prep

A repo that looks clean on its default branch can still leak things once it's public, because GitHub serves more than main: every branch, every tag, and every closed/merged pull request's diff stay browsable (and git fetch origin refs/pull/N/head still works) for as long as the repository exists. Scanning only the current tree, or only git log main, misses whatever was fixed, force-pushed over, or squash-merged along the way — which is exactly the stuff people forget is still sitting there.

The job here has two parts: find everything that's actually reachable, then help the user pick a remediation that matches how bad it is. Don't skip straight to "let's squash it" — squashing only rewrites branches you control; it does nothing to old PR pages or tags, which is a common surprise.

Step 1: Scan the full exposure surface

Run the bundled script, which fetches every ref and scans both the current tip (what's immediately visible) and the full history (what's technically reachable):

bash scripts/scan_history.sh /path/to/repo

It prints a working directory containing:

• tip_emails.txt, tip_paths.txt, tip_secrets.txt — hits in the current default-branch tree
• history_secrets.txt, history_emails.txt, history_paths.txt, history_ips.txt — hits anywhere across all branches/tags/PR refs
• identities.txt — every distinct commit author/committer identity ever used in the repo
• tag_reachability.txt — for each tag, whether it's an ancestor of a live branch or a dangling artifact only reachable by its own ref

The regexes are a starting point, not the whole job. Read through the hits yourself — greps produce false positives (template placeholders like [email protected], doc examples of what not to hardcode) and false negatives (a script's .filter(Boolean)-style approach won't catch a company name or a person's name that isn't in an email or path pattern). When something looks interesting, pull the surrounding context and the commit it's from: