Launch your Graphy
There are no items in your cart
Add More
Add More
| Item Details | Price | ||
|---|---|---|---|
Every student's GitHub journey starts the same way: you build something, you run git add ., you run git commit, and you push. It feels great — until the day you push a file that contains your database password, your OpenAI API key, or your college email's app password, and it sits in a public repository for anyone (including bots that scan GitHub 24/7) to find.
This isn't a rare mistake. It's one of the most common security incidents in student projects, hackathons, and even production startups. The good news: GitHub actually gives you a full toolkit to prevent, catch, and recover from exactly this problem — most students just never learn where it is. That's what this guide covers.
01 — Why "secrets" leak in the first place
Before the fixes, it helps to see exactly how a secret sneaks into a commit.
A "secret" is any piece of information that grants access to something — an API key, a database URL with a password baked in, an SSH private key, a cloud storage token, or even a hardcoded admin password used "just for testing." Most leaks happen because a secret is typed directly into source code instead of being kept separate from it, and then the whole folder gets committed with a simple git add .
Reality check: GitHub's public repositories are scraped by automated bots within minutes of a push. Leaked AWS keys have led to thousands of dollars in cloud bills run up by attackers — on student accounts — in a single night.
02 — The 10 secrets, explained
These are the GitHub features and habits that separate students who get burned from students who don't.
tip_01 · .gitignore
.gitignore is your first line of defense
A .gitignore file tells Git which files to never track — .env, node_modules/, *.log, config files with credentials. Create it before your first commit, not after.
.env *.key config/secrets.jsontip_02 · Environment Variables
Keep keys in .env, never in code
Instead of writing const apiKey = "sk-abc123" directly, store it in a .env file and read it with process.env.API_KEY. The .env file itself goes straight into .gitignore.
tip_03 · GitHub Actions Secrets
Repo Settings → Secrets and variables
If your project uses GitHub Actions (CI/CD), never paste keys into the workflow YAML. Add them under Settings → Secrets and variables → Actions, then reference them as ${{ secrets.MY_KEY }}. They're encrypted and hidden from logs automatically.
tip_04 · Fine-Grained Tokens
Personal Access Tokens (PATs) with limits
When Git asks for a password over HTTPS, it now wants a token, not your account password. Generate a fine-grained PAT under Settings → Developer settings, scope it to one repo, and set an expiry date — 30 or 90 days, never "no expiration."
tip_05 · SSH Keys
Switch to SSH for a smoother, safer login
An SSH key pair lets you push and pull without typing a token every time. The private key stays on your laptop, only the public key goes to GitHub. Generate one with ssh-keygen -t ed25519 and never share the private half.
tip_06 · Secret Scanning & Push Protection
Let GitHub catch you before you push
GitHub automatically runs secret scanning on public repos and can enable push protection, which actively blocks a push that contains a recognizable secret pattern (like an AWS key format) — the exact warning shown in the terminal above.
tip_07 · Revoke, Don't Just Delete
Deleting a commit does not undo a leak
If a secret was ever pushed — even once — assume it's compromised, because it may already be cached, forked, or scraped. The correct fix is to revoke/rotate the actual key at the provider (AWS, OpenAI, Firebase, etc.), then clean the Git history.
tip_08 · Rewriting History
git filter-repo & BFG Repo-Cleaner
To actually remove a secret from every past commit (not just the latest one), tools like git filter-repo or the BFG Repo-Cleaner rewrite history and strip the file everywhere it ever appeared, followed by a force-push.
tip_09 · Branch Protection + 2FA
Lock your main branch, lock your account
Enable two-factor authentication on your GitHub account (GitHub now requires it for many contributors), and turn on branch protection rules so no one — including you, half-asleep at 2 a.m. — can force-push straight to main.
tip_10 · Private ≠Permanently Safe
Private repos still need discipline
A private repository lowers risk but does not eliminate it — collaborators, forks after going public, and leaked tokens in screenshots or Discord messages are common leak paths students overlook. Treat every secret the same way regardless of repo visibility.
03 — PAT vs SSH vs OAuth — what should you actually use?
Students often get stuck deciding how to authenticate. Here's the practical breakdown.
| Method | Best for | Expires? | Setup effort |
|---|---|---|---|
| Fine-grained PAT | HTTPS pushes, scripts, CI | Yes — you set it | Low |
| SSH key | Daily local development | No, unless rotated manually | Medium (one-time) |
| OAuth App token | Third-party apps & integrations | Yes, revocable anytime | Handled by the app |
| Classic PAT | Legacy scripts only | Often "no expiration" | Low (but risky) |
Recommendation: use SSH for your own laptop, fine-grained PATs for anything scripted or CI-related, and avoid classic tokens with no expiry entirely.
04 — A safe project setup, step by step
This is the exact sequence to follow on day one of any new project.
terminal
# 1. Create the repo folder and initialize git mkdir my-project && cd my-project git init # 2. Create .gitignore BEFORE your first commit echo ".env" >> .gitignore echo "node_modules/" >> .gitignore echo "*.key" >> .gitignore # 3. Create your environment file (never committed) echo "API_KEY=your_real_key_here" > .env # 4. Now it's safe to add and commit git add . git commit -m "initial commit"
Notice the order: .gitignore is created before the first git add. This one habit alone prevents the majority of student secret leaks.
05 — "I already pushed a secret." Now what?
Panic is optional. Follow these steps in order — speed matters more than perfection.
- Rotate the key immediately. Go to the provider (AWS, Firebase, OpenAI, Mongo Atlas, etc.) and revoke or regenerate it. This matters more than anything else on this list.
- Check billing / usage dashboards for any unexpected activity in case the key was already used.
- Remove the secret from history using
git filter-repoor BFG Repo-Cleaner, not just a new commit that deletes the line. - Force-push the cleaned history and ask any collaborators to re-clone the repo.
- Add the file to .gitignore so it can never be re-committed by accident.
06 — Tools worth installing this week
These take five minutes to set up and catch mistakes before they ever reach GitHub.
gitleaks
Scans your repo and commit history for hardcoded secrets before you push.
git-secrets
AWS-maintained tool that blocks commits matching known secret patterns.
TruffleHog
Deep-scans entire git history, including old commits, for exposed credentials.
pre-commit hooks
Runs a scanner automatically every time you type git commit, locally.
07 — Quick recap
If you remember nothing else from this post, remember these five lines.
cheat-sheet.md
1. Write .gitignore before your first commit. 2. Secrets live in .env or GitHub Actions Secrets — never in code. 3. Use fine-grained tokens with an expiry date, not classic PATs. 4. A leaked key is never "safe" once pushed — rotate it immediately. 5. Turn on 2FA and branch protection today, not "eventually."