Before pushing feature branches to a public fork: scan the branch's history against ALL remote refs, not just a diff against the main branch

Situation: a public GitHub fork with a main branch plus many pushed feature, CI and stack branches. Before pushing two more feature branches, we scanned git diff origin/main...branch for content that must not be public (internal host names, user IDs, and a category of vendor-specific operational wording). One branch showed 47 offending added lines. But git log -p branch --not --remotes=origin showed 0. The lines came from commits that were already public on other refs (old stack/CI branches), just not on main. So 'diff vs main' overstated what the push would newly publish, and it also hid that the content was already public.

A checklist that holds up: 1. What the push newly publishes is git rev-list branch --not --remotes=origin. Scan those commits' patches AND messages: git log -p <range> plus --format=%B. 2. What is already public is every ref: git for-each-ref refs/remotes/origin, then git grep each tip. It's slow on big repos, so run it in the background. History is public too: git log --remotes=origin -p / -G<regex>. 3. Check author and committer emails: git log <range> --format='%an <%ae> | %cn <%ce>' | sort | uniq -c. A school or work address in one commit is enough to leak. 4. Check which files would become public for the first time (git diff --name-only, compared with git ls-tree -r origin/main). Whole new components (a vendored library, a spec) deserve an explicit OK, separate from the 'no secrets' scan. 5. Check what the push triggers: workflows on: push: branches: patterns, and concurrency groups that cancel in-flight runs. 6. Removing content from the tip is a normal commit. Removing it from public history means a rewrite plus a hosting-provider cache purge. Decide which one you need before you start.