GitHub Public vs Private + Permissions Guide

“Is GitHub safe for client work?” comes up weekly in r/freelance and r/cscareerquestions. The answer depends on what you mean by safe — visibility, IP protection, security, or compliance. This guide walks each.

Private vs public repos

• Public: anyone can read. You control who can write. Free for unlimited repos. Visible to search engines.
• Private: only invited collaborators can read or write. Free for unlimited repos (since 2019). Not visible to search engines or non-collaborators.

The default is private for new repos. Make sure you check before pushing anything sensitive.

Is GitHub safe for client projects?

For most freelance + agency work: yes, with sensible setup.

• Use private repos for client work. Add the client as a collaborator if they want access; otherwise keep it to your team.
• Don’t commit secrets. Use environment variables; configure the client’s secrets via GitHub Actions secrets or their cloud provider’s secret manager.
• Sign NDAs first. If client requires it, GitHub Enterprise Cloud or Enterprise Server has the compliance features (SAML SSO, audit logs, longer retention).
• Transfer the repo at project end. GitHub has a built-in repo transfer flow. Move it to the client’s org when the engagement ends.

For HIPAA / FedRAMP / similarly regulated work: GitHub Enterprise Cloud is compliant. Confirm specific requirements with the client’s compliance team before committing.

How would I know if my code was stolen on GitHub?

Practical detection:

• GitHub code search. Search distinctive strings from your code. Catches direct copy-paste theft.
• Sourcegraph public search. Same idea, different index. Sometimes catches what GitHub search doesn’t.
• Distinctive variable names + comments. Add unusual identifiers to your code. Plagiarism detection becomes trivial.
• License signal. If your repo is MIT/Apache, “stealing” is mostly attribution failure. Add a clear LICENSE file.

For genuinely critical IP: don’t put it on GitHub at all. Use a private repo with strict access controls, or self-host on GitLab/Gitea.

GitHub permissions + production safety

The branch protection rules that prevent breaking production:

• Required reviews. Block merge to main without N approvals.
• Required status checks. Block merge until CI passes.
• No force-push. Prevents history rewriting on main.
• Restrict who can push. Limit deploy-related branches to specific roles.
• Code owners. Require specific people to approve changes to specific paths (e.g. infra dirs require infra-team approval).

Set these on day 1 for any team repo. Teams that skip them eventually have a “why did this break production?” incident that traces to a missing protection rule.

Can I download someone else’s code and use it legally?

Depends on the license:

• MIT, Apache 2.0, BSD: permissive. You can use, modify, distribute, even commercially. Must include attribution.
• GPL, AGPL: copyleft. If you distribute software using GPL code, your software must also be GPL. AGPL extends this to network-served software.
• No license: default copyright applies. You can’t legally use it without permission, even if it’s public on GitHub.
• “Source available” (BSL, Elastic License): somewhere in between. Read the specific terms — usually allows internal use but restricts hosting as a competing service.

What happens to my code if GitHub gets hacked?

GitHub has had security incidents but no full-database breach to date. The practical risks:

• Account compromise. Most common. Mitigate with 2FA + a password manager.
• Token leakage. Personal Access Tokens accidentally committed to public repos. GitHub Secret Scanning catches most of these automatically.
• Provider-wide breach. Hypothetical. The realistic mitigation is keeping local clones (you have them anyway) and not relying on GitHub as your only backup.

For genuinely critical code: mirror to a second provider (GitLab, Bitbucket, self-hosted Gitea) on a periodic schedule. Never have a single point of failure.

Stopping API keys from getting leaked

Standard practices:

• Never commit secrets. Use .env files (gitignored), GitHub Actions secrets, or cloud secret managers.
• GitHub Secret Scanning. Free, scans for known token patterns (AWS, Stripe, etc.). Auto-rotates some tokens via partner integrations.
• Pre-commit hooks. Tools like git-secrets or trufflehog prevent committing tokens locally.
• Rotate tokens regularly. Even with prevention, assume some will leak. Short token lifetimes limit damage.
• If a token leaks: rotate immediately, audit access logs, force-push removal won’t help (Git history persists in clones — consider it permanently exposed).