Publishing to GitHub Safely

Making your code public is exciting — but it requires caution. Once you push something to a public repository, anyone can see it. That includes API keys, passwords, and personal information you might have accidentally included.

The good news: a few simple checks prevent most problems.

Never Commit Secrets

The most common mistake is committing API keys or credentials directly in code. Even if you delete them later, they remain in your Git history.

Check your code for:

  • API keys hardcoded in files
  • Database passwords
  • Personal access tokens
  • Private URLs or endpoints

Use environment variables instead. Store secrets in a .env file that's excluded from Git.

Set Up .gitignore Properly

Your .gitignore file tells Git which files to exclude. Before publishing, verify it includes:

# Environment and secrets
.env
.env.local
*.pem
secrets.json

# Dependencies (can be reinstalled)
node_modules/
venv/
__pycache__/

# Build outputs
dist/
build/
*.pyc

# Editor files
.vscode/
.idea/

Pre-Push Checklist

Before making your repository public, review this checklist:

  • No API keys in code
  • .env is in .gitignore
  • No passwords or credentials
  • No personal data (real names, emails, addresses)
  • Sensitive comments removed
  • README is up to date
  • License file included

Choose a License

If you want others to use your code, include a license file. Without one, your code is technically "all rights reserved" by default.

Common choices:

  • MIT — Very permissive, lets anyone do almost anything
  • Apache 2.0 — Similar to MIT with patent protections
  • GPL — Requires derivative works to also be open source

GitHub can add a license file when you create a repository, or you can add one later.

Repository Settings

When publishing, add helpful metadata:

  • Description — One sentence explaining your project
  • Topics — Tags like "python", "cli", "stock-market" help people find your project
  • Website — Link to live demo if you have one

If You Accidentally Commit Secrets

If you've already pushed secrets, changing the file isn't enough — the secret is still in your Git history. You'll need to rotate the compromised credential (generate a new API key) and consider using tools like git filter-branch or BFG Repo-Cleaner to remove the secret from history.

Prevention is much easier than cleanup.

See More

Further Reading

You need to be signed in to leave a comment and join the discussion