Skip to content

GitHub Workflow & Branch Protection

This document describes the GitHub repository configuration optimized for solo developer workflow while maintaining code quality.

Branch Protection Rules (main)

Rule Setting Purpose
Required status checks frontend-test, backend-test, security-scan-dependencies Ensures CI passes before merge
Strict status checks Enabled Branch must be up-to-date with main
Required signatures Disabled Removes GPG signing friction for solo dev
Enforce admins Disabled Owner can bypass rules when needed
Required PR reviews Disabled No approval needed for solo dev
Linear history Enabled Clean, readable git history
Force pushes Disabled Protects commit history
Deletions Disabled Prevents accidental branch deletion

Workflow Options

# Make changes
git add .
git commit -m "feat: add new feature"
git push origin main

The pre-push hook runs local tests. If they pass, the push proceeds and CI runs on GitHub.

Option 2: Feature Branch + PR (For Complex Changes)

# Create feature branch
git checkout -b feature/new-feature

# Make changes and push
git add .
git commit -m "feat: add new feature"
git push -u origin feature/new-feature

# Create PR
gh pr create --title "feat: add new feature" --body "Description"

# After CI passes, merge
gh pr merge --squash

Quality Gates

Local (Pre-push Hook)

Located at .githooks/pre-push, runs before every push:

  1. Backend tests - Django unit tests (subset for speed)
  2. TypeScript check - tsc --noEmit
  3. Frontend tests - Jest with coverage
  4. CodeRabbit review - AI code review (non-blocking)

Remote (GitHub Actions CI)

Runs on every push to main:

  1. frontend-test - Full Jest test suite
  2. backend-test - Full Django test suite
  3. security-scan-dependencies - npm audit, pip-audit, Trivy
  4. docker-build - Validates Docker images build
  5. e2e-smoke-test - Playwright smoke tests

GitHub Pro Features Used

Feature Usage
3,000 Actions minutes/month Heavy CI pipeline (tests, E2E, Docker)
Private repo CI All CI runs on private repository
Branch protection Status checks without PR requirement

Changing Branch Protection

Via GitHub CLI

# View current settings
gh api repos/Voorman/webshop_freeze_design/branches/main/protection

# Update settings
gh api repos/Voorman/webshop_freeze_design/branches/main/protection -X PUT \
  --input - << 'EOF'
{
  "required_status_checks": {
    "strict": true,
    "checks": [
      {"context": "frontend-test"},
      {"context": "backend-test"},
      {"context": "security-scan-dependencies"}
    ]
  },
  "enforce_admins": false,
  "required_pull_request_reviews": null,
  "restrictions": null,
  "required_linear_history": true,
  "allow_force_pushes": false,
  "allow_deletions": false
}
EOF

# Enable/disable signature requirement
gh api repos/OWNER/REPO/branches/main/protection/required_signatures -X POST  # Enable
gh api repos/OWNER/REPO/branches/main/protection/required_signatures -X DELETE # Disable

Via GitHub UI

  1. Go to Settings → Branches → Branch protection rules
  2. Click Edit on main
  3. Modify settings as needed

Future Considerations

When to Add PR Requirements

Consider enabling required PR reviews if:

  • You add team members
  • You want enforced code review
  • Compliance requirements change

When to Add GPG Signing

Consider enabling required signatures if:

  • Working on security-sensitive features
  • Contributing to open source
  • Corporate compliance requires it

To setup GPG signing:

# Generate GPG key
gpg --full-generate-key

# Get key ID
gpg --list-secret-keys --keyid-format=long

# Configure Git
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true

# Add public key to GitHub
gpg --armor --export YOUR_KEY_ID | pbcopy
# Paste at: GitHub → Settings → SSH and GPG keys → New GPG key

Architecture Decisions

Task Queue: Celery (Decision: January 2026)

Decision: Keep Celery + Redis instead of migrating to Django 6.0 Tasks.

Reasons: - Django Tasks backend still in beta (not production guaranteed) - Celery is battle-tested (10+ years) - Current setup works reliably - Low task volume (~50/day) doesn't justify migration risk - €20-40/mo savings not worth beta risk for e-commerce

Revisit when: - Django Tasks backends reach v1.0 stable - Django 6.1+ released with matured ecosystem - Task volume significantly increases

Alternatives considered: - Django Tasks + django-tasks (too new) - Django-Q2 (viable alternative if Celery issues arise)