Repo Strategy — Public vs Private Repos, Branch Approva...

Every codebase eventually hits the question: public or private. The wrong answer in either direction costs you. Too public and you ship secrets or dilute a competitive moat; too private and you forfeit the authority signal that an active public repo generates in Google and in AI models' entity graphs. The right answer depends on the repo, not the company.

This post covers four things. When to choose public vs private. What branch approvals actually do and how to configure them. The GitHub alternatives worth knowing. And a separate privacy-focused tier. Tor, Proton, the legal framing around it. That exists for legitimate reasons most writers won't cover because it sounds edgy.

Public vs Private. The Framework

Make a repo public when:

It's demonstrating capability or methodology (a reference implementation, an SDK example, a showcase of approach).
It's a library or tool you want other people to use and contribute back to.
The value is in the artifact, not the process (generated content, data outputs, deployment configs for public projects).
You want it as a sameAs signal for your brand. A real, active public repo carries real E-E-A-T weight.

Make a repo private when:

It contains credentials, API keys, secrets, or infrastructure details. (Even with .gitignore and secrets managers, the risk surface is non-zero.)
The code is the product. Proprietary SaaS, client deliverables, vendor-locked integrations.
The code is actively evolving with security implications where exposure would enable attacks (pentest tooling, vulnerability research).
You haven't decided yet. Private is the safe default; you can always flip to public later. The reverse direction is hard. Git history forever.

The middle ground most teams miss: internal-visible repos. GitHub and GitLab both support org-scoped visibility (visible to everyone in the org, invisible outside). That's the right setting for most business code. Shared across the team, not exposed to the internet.

Branch Approvals. What They Actually Do

Branch protection rules live on the branch, not the repo. A typical production setup:

Protect the default branch (main / master). Nobody commits directly. All changes go through pull requests. This is step one. Without it, everything else is optional.

Require N approving reviews. One is the usual default; bump to two for regulated industries or sensitive code paths. Self-approval doesn't count by default (that's what "dismiss stale approvals" and "require approval from a code owner" enforce).

Require status checks to pass. CI tests, linting, security scanning. The branch can't merge until all named checks return green. This is the "can't ship broken code" gate.

Require linear history. Blocks merge commits; forces squash or rebase. Makes git bisect reliable when you need to find the commit that broke something.

Require signed commits. Every commit has to be GPG-signed. High-paranoia setting. Typically only for security-sensitive repos. The trade-off is onboarding friction; every contributor needs to set up GPG.

Restrict who can push. Even with PR workflow, you can restrict the merge button to specific users or teams. Sensible for release branches. Let engineers approve, but only a release manager merges.

CODEOWNERS file. A CODEOWNERS file in .github/ (or docs/ or root) maps paths to required reviewers. Edit src/payment/ and the payment team is auto-added as a required reviewer. Great for horizontal ownership in larger orgs.

For a solo developer: protect main, require one review (from yourself, on a PR you opened from a branch), require CI to pass. That's the minimum. Every additional rule earns its keep only when you have a team or a compliance story.

GitHub Alternatives. The Ones Worth Knowing

GitHub is the default for good reason. Ecosystem, Actions, discoverability, Copilot integration. But it's not the only choice, and there are legitimate reasons to pick something else.

GitLab. The closest full-feature alternative. Self-hosted CE (Community Edition) is free; SaaS tiers parallel GitHub's. Stronger CI/CD built in (GitLab CI is arguably more powerful than GitHub Actions for complex pipelines). Popular in regulated industries because self-host is genuinely first-class.

Gitea / Forgejo. Self-hosted, lightweight, open-source. Forgejo is a community-governed fork of Gitea with more active open-source governance. Pick one if you want a GitHub-style interface running on your own hardware (a Raspberry Pi is fine for personal-scale use).

Codeberg. Public nonprofit hosting built on Forgejo. Free, community-run, based in Germany. So subject to EU data protection rather than US. Good for open-source projects that want to live on infrastructure that isn't US-based SaaS.

Sourcehut. Minimalist, paid (about $2/month), email-patch-driven. Loved by a specific slice of the Linux/BSD community. Unusually well-built; unusual workflow.

Radicle. Peer-to-peer git without a central server. Uses the same git you already have; layers a sync protocol on top. Still early but the direction is interesting. Code hosting without anyone's cloud.

Tangled. Git forge built on the AT Protocol (same protocol Bluesky uses). Very early. Worth watching if you're interested in decentralized identity.

Most teams pick one and never switch. That's fine. The value of knowing the alternatives is having an informed answer when the question comes up. Especially for non-US teams or regulated workloads where "on a US-based SaaS" is actually a problem.

The Privacy Tier. Tor, Proton, And Why This Exists

There is a separate tier of code hosting that lives on Tor hidden services (.onion addresses) and privacy-focused email infrastructure like Proton. Writing about it responsibly means covering what it's legitimately for and what the legal framing looks like before getting into the how.

Who uses this tier, legitimately

Journalists and their sources. SecureDrop is the canonical example. A Tor-only submission system many major newsrooms run (The New York Times, The Washington Post, The Guardian, ProPublica, BBC, Der Spiegel, and many others). Sources leak documents to journalists without exposing their IP, their ISP, or the fact that the contact happened.

Researchers in authoritarian or high-surveillance jurisdictions. A developer in a country where certain code or documentation is restricted (this is a real list of countries and it changes) needs some way to work with the global open-source community. Tor is often the bridge.

Whistleblowers. Tor + a privacy-focused email provider is standard operational security for anyone who has information a powerful entity wants to suppress.

Security researchers. Pentesters, red-teamers, and vulnerability researchers need to exchange sensitive proof-of-concept material without ISP-level logging identifying them as connected to a specific target before disclosure.

Activists and human-rights workers. Documenting abuses, coordinating across borders, supporting domestic-violence survivors whose abusers monitor their network traffic.

None of this is hypothetical. Every major democratic government in the world, including the US, publicly funds Tor development in part because the free flow of information it enables is a foreign-policy interest.

What the law actually says

Using Tor and Proton is legal in the United States, Canada, the UK, most of the EU, Japan, Australia, New Zealand, South Korea, and most other democracies. The tools themselves are privacy tools. Nothing about running a Tor Browser session, using proton.me for email, or accessing a .onion hidden service is illegal in those jurisdictions.

A short list of places where it's restricted or blocked: China (blocked), Iran (blocked), Russia (blocked since 2022), Belarus (blocked), Turkmenistan (blocked), Venezuela (restricted). A few more jurisdictions have partial or intermittent restrictions. If you're in one of these, the risk profile is different and this post can't substitute for local legal counsel.

What's illegal is illegal whether you use Tor or not. Fraud, unauthorized access to systems, distribution of CSAM, targeted harassment. The law doesn't care about the network layer. Tor doesn't confer legal cover; it confers anonymity from surveillance, which is a different thing. The distinction matters because a lot of online writing conflates "privacy tool" with "crime tool" and they are not the same.

How to interface with the privacy tier

Install Tor Browser from torproject.org. Always the official site. Fake Tor installers are a known attack vector. Verify the download signature if you want to be rigorous (the project documents how).

Use Proton Mail at proton.me for end-to-end encrypted email. Free tier is adequate for most use cases; paid tiers add custom domains and larger storage. Proton also offers VPN, Drive, Pass. All similarly designed.

Access known-good hidden services for legitimate purposes. A short list:

SecureDrop landing. securedrop.org lists the .onion addresses of every major newsroom running a SecureDrop instance.
ProPublica runs one of the oldest news-org .onion sites.
BBC has a .onion mirror for audiences in censored jurisdictions.
The New York Times runs nytimes3xbfgragh.onion.
ProtonMail's onion: protonmailrmez3lotccipshtkleegetolb73fuirgj7r4o4vfu7ozyd.onion.
DuckDuckGo's onion: duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion.

Code hosting on Tor exists but is mostly small-scale. Some self-hosted Gitea instances run hidden services alongside their clearnet domains. Cryptohagen and a handful of other infrastructure projects maintain .onion mirrors. The pragmatic path for most projects is: clearnet GitHub or GitLab for discoverability, with issue threads and sensitive disclosures handled through a .onion SecureDrop-style intake if the threat model warrants it.

What not to do. And this is the part that has to be said explicitly. Don't use Tor to access markets that sell illegal goods. Don't use it to evade law enforcement for illegal activity. Don't use it to harass people. Don't download or distribute CSAM. These aren't privacy uses; they're criminal uses, and the law treats them as such regardless of the network. If this post is the first place you've read about Tor and your first instinct is "this is how I get access to illegal stuff," step back. That is not what this is about, and this post will not help you with it.

Operational security basics

For legitimate use. Journalism, research, activism, vulnerability disclosure. The basics:

Keep Tor Browser updated. Old versions have known exploitable bugs.
Don't log in to clearnet accounts over Tor. Correlation attacks are trivial once you do.
Disable JavaScript on .onion sites unless you trust them. Most high-value hidden services (SecureDrop, ProtonMail) work without JS.
Use a separate Tor identity per purpose. Tor Browser has a "New Identity" button for a reason.
Understand your adversary model. The thing that compromises you is usually boring. Using your real name once, uploading a file with EXIF metadata, accessing a public account. Not anything exotic.

When a business should care

Most small businesses don't need any of this. Clearnet, good passwords, 2FA, normal backups. That's enough. The reason to know it exists:

You take whistleblower or vulnerability reports. (Run a .onion intake next to your clearnet one.)
You operate across jurisdictions where the risk profile genuinely differs. (Subsidiaries in restrictive countries.)
Your customer list includes activists, journalists, or human-rights workers. (Offer Proton-friendly delivery of sensitive artifacts.)
Your code base contains research with dual-use implications. (Some security research is better disclosed via a private channel before clearnet publication.)

If none of those apply to your business, clearnet-only is fine. Most businesses are clearnet-only businesses.

Where this fits in the jwatte.com toolchain

The GitHub Authority Score and GitHub Repo Visualizer both work on public repos. That's the tier where the entity-graph signal lives and where AI models can cite your work. Private and mirror-on-Tor repos don't contribute to public authority (by design); they're in a different category entirely.

If your work is sensitive enough that public hosting is the wrong answer, that's a conscious trade-off. The authority-signal gain you'd have gotten is paid for by other trust signals. Published papers, attributed case studies, Wikidata entries, press coverage. The Entity Citation Radar is what you use to verify that tradeoff is actually working.

Methodology cross-references: Chapter 2 of The $97 Launch, GitHub as Your Content Engine, makes the case for public repos as an authority asset. Chapter 47 of The $100 Network, Legal Structure and Compliance for Multi-Site Operations, is the book-length companion on compliance framing for multi-jurisdiction work.

Legal & safety disclaimer. This post is educational commentary on lawful privacy tools and legitimate use cases. It is not legal advice. Laws differ by country and US state and change over time. Verify current law in your jurisdiction before acting on anything here. The Tor Project, ProtonMail, SecureDrop, and related technologies described are lawful privacy tools in most democratic jurisdictions. Illegal acts remain illegal regardless of network technology used. If your situation involves whistleblower protection, harassment, threats to safety, or other sensitive contexts, consult a qualified attorney and. Where relevant. Organizations like the Electronic Frontier Foundation (eff.org), Freedom of the Press Foundation (freedom.press), or local equivalents in your jurisdiction.

Repo Strategy — Public, Private, Branch Approvals, And The Privacy Tier Most People Skip