DEV Community

K-kibet
K-kibet

Posted on

GitHub Push Protection: How I Fixed the "Repository Rule Violations" Error

#git #github #api #cli

GitHub Push Protection Error

Photo by @flyd2069 on Unsplash

The Moment of Panic

It was a typical Tuesday afternoon. I was working on my PayStack Complete API project, making some final tweaks before pushing to GitHub. I ran the usual commands:

git add .
git commit -m "Updated environment configuration"
git push -u origin main
Enter fullscreen mode Exit fullscreen mode

And then it happened - the dreaded red text:

remote: error: GH013: Repository rule violations found for refs/heads/main.
remote: - GITHUB PUSH PROTECTION
remote: —————————————————————————————————————————
remote:   Resolve the following violations before pushing again
remote: - Push cannot contain secrets
Enter fullscreen mode Exit fullscreen mode

My heart sank. GitHub had detected a Stripe API Key in my commit history and blocked the push. The violation was clear:

  • Secret Type: Stripe API Key
  • Location: Commit 47b22e5f1d4a9bc6......
  • File: .env:6

Understanding the Problem

GitHub's Push Protection is a security feature that scans for accidentally committed secrets like API keys, tokens, and credentials. It's designed to prevent security breaches before they happen.

In my case, I had committed a .env file that contained:

DATABASE_URL=your_database_url
JWT_SECRET=your_jwt_secret
STRIPE_API_KEY=sk_live_xyz123abc456  # This was the culprit
Enter fullscreen mode Exit fullscreen mode

The mistake was common but dangerous: I had committed sensitive credentials to version control.

The Wrong Approach: Force Push

Like many developers, my first instinct was to try forcing my way through:

git push -u origin main --force
Enter fullscreen mode Exit fullscreen mode

Bad idea. GitHub's security measures are smarter than that. The push protection held firm, and I received the same error message.

The Real Solution: Cleaning House

After some research and deep breaths, I implemented the proper solution. Here's the step-by-step process that actually worked:

Step 1: Remove the Sensitive File from Tracking 

# Remove .env from git without deleting it locally
git rm --cached .env
Enter fullscreen mode Exit fullscreen mode

Step 2: Secure Your Project with .gitignore 

# Ensure .env is in .gitignore
echo ".env" >> .gitignore

# Add other common files you don't want tracked
echo "node_modules/" >> .gitignore
echo "*.log" >> .gitignore
echo ".DS_Store" >> .gitignore
Enter fullscreen mode Exit fullscreen mode

Step 3: Rewrite Git History

This is the crucial step that removes the secret from your entire commit history:

# Remove the file from all commits in history
git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch .env' \
  --prune-empty --tag-name-filter cat -- --all
Enter fullscreen mode Exit fullscreen mode

Step 4: Clean Up and Push 

# Clean up the repository
git gc --aggressive --prune=now

# Push the cleaned history
git push origin main --force
Enter fullscreen mode Exit fullscreen mode

Alternative Approach: Reset and Recommit

If you have fewer commits and want a simpler approach:

# Reset to before the secret was added
git reset --hard HEAD~1

# Fix your .env file (remove the actual API key)
# Then recommit cleanly
git add .
git commit -m "Fix: Remove sensitive credentials"
git push origin main
Enter fullscreen mode Exit fullscreen mode

Best Practices I Learned the Hard Way

1. Never Commit .env Files

Your .env file should be in .gitignore from day one. Create a .env.example file with placeholder values instead.

2. Use Environment Variables Properly

In your code, always reference environment variables:

// Good
const stripe = require('stripe')(process.env.STRIPE_API_KEY);

// Bad
const stripe = require('stripe')('sk_live_xyz123abc456');
Enter fullscreen mode Exit fullscreen mode

3. Rotate Exposed Credentials

If you've accidentally exposed API keys:

  1. Immediately rotate them in your service provider's dashboard
  2. Update all your applications with the new keys
  3. Audit your access logs for any suspicious activity

4. Use GitHub Secrets for CI/CD

For deployment, use GitHub Actions secrets or your platform's equivalent secure environment variable storage.

The Aftermath

After implementing the proper solution, my push went through smoothly. More importantly, I had:

  1. Secured my application by removing exposed credentials
  2. Established better practices for future projects
  3. Learned to appreciate GitHub's security features

Key Takeaways

  • GitHub Push Protection is your friend, not your enemy
  • Environment variables belong in environment, not in version control
  • Security is a process, not an afterthought
  • When you make a mistake, fix it properly rather than trying to force your way through

Tools That Can Help

  • pre-commit hooks: Scan for secrets before committing
  • git-secrets: AWS's tool for preventing committed secrets
  • truffleHog: Scans git history for secrets
  • GitGuardian: Comprehensive secret detection

The next time you see that "Repository rule violations" error, don't panic. Take it as an opportunity to improve your security practices and protect your applications.

Have you encountered GitHub Push Protection? Share your experiences and tips in the comments below!

Disclaimer: The code examples and commit hashes in this article are fictionalized for educational purposes. Always follow your organization's security protocols when handling sensitive credentials.

Top comments (0)