Developer Tools

Git Security Best Practices

Keep your repository secure. Prevent secrets in code, protect branches, and maintain a clean git history.

Scan for Exposed Secrets

Security Best Practices

Never Commit Secrets

API keys, passwords, and credentials should never be in your repository—even in private repos.

Implementation: Use .gitignore for .env files. Use git-secrets or pre-commit hooks to catch accidental commits.

Use .gitignore Before First Commit

Set up .gitignore before adding any files. Once secrets are committed, they're in history forever.

Implementation: Create .gitignore first. Include: .env, *.pem, *.key, node_modules/, credentials.json

Enable Branch Protection

Protect main branches from direct pushes. Require reviews and status checks.

Implementation: GitHub/GitLab: Settings > Branches > Add rule. Require PR reviews, status checks.

Sign Your Commits

Signed commits prove authenticity. Important for supply chain security.

Implementation: Set up GPG key. git config commit.gpgsign true. Verify signatures on GitHub.

Enable Secret Scanning

Automatically detect secrets that were accidentally committed.

Implementation: GitHub: Settings > Security > Secret scanning. Also consider third-party tools.

.gitignore Essentials

.env
.env.*
*.pem
*.key
*.p12
*credentials*
*secret*
.aws/
.gcloud/
node_modules/
.DS_Store
*.sqlite
*.db
config/local.json
config/production.json

Add this to your .gitignore before making your first commit. Customize based on your stack.

Secret Prevention Tools

git-secrets

AWS tool to prevent committing secrets

brew install git-secrets && git secrets --install
pre-commit

Framework for managing pre-commit hooks

pip install pre-commit && pre-commit install
gitleaks

Scan git repos for secrets

brew install gitleaks
trufflehog

Find credentials in git history

brew install trufflehog

If You've Already Committed Secrets

  1. Rotate immediately - The secret is compromised. Change it now.
  2. Remove from history - Use BFG or git filter-branch
  3. Force push - Coordinate with team first
  4. Check for exposure - Search for your secret on GitHub, Shodan, etc.
  5. Add protections - Set up pre-commit hooks to prevent recurrence

Check for Exposed Secrets

VAS scans your deployed application for exposed credentials and API keys— the kind of secrets that end up in git history.

Free Security Scan

Frequently Asked Questions

I accidentally committed a secret. What do I do?

1) Rotate the secret immediately—assume it's compromised, 2) Remove from history using git filter-branch or BFG Repo Cleaner, 3) Force push (coordinate with team), 4) Enable secret scanning to prevent recurrence. Note: If pushed to public repo, bots may have already captured it.

Are private repositories safe for secrets?

No. Private repos still have risks: team members leaving, accidental public exposure, compromised accounts, repo cloning. Never put secrets in git, even in private repos. Use environment variables, secret managers, or CI/CD secrets.

Do I need signed commits?

For most projects, it's nice-to-have. For security-sensitive or open-source projects, it's important—it proves commits came from who they claim. Required for some compliance frameworks. At minimum, enable for main branch merges.

How do I scan my git history for secrets?

Use trufflehog: `trufflehog git file://./` or gitleaks: `gitleaks detect`. These scan entire history. For ongoing protection, use pre-commit hooks to prevent new secrets from being added.

What should always be in .gitignore?

Environment files (.env), key files (*.pem, *.key), local config (config/local.json), credentials files, database files (*.sqlite), dependencies (node_modules/), OS files (.DS_Store), IDE config (.idea/, .vscode/).

Related Resources

Exposed API KeysSecurity ChecklistSecurity MistakesNPM Security Risks

Last updated: January 16, 2026