Git Integration

Git is your safety net: it lets you ship GeneratePress customizations (child themes, MU-plugins, small site plugins) with confidence, review changes, and roll forward quickly.

What Belongs in Git

Include	Why	Exclude	Why
Child theme code	Deployable, reviewable	uploads/	Huge, not code
MU-plugins / site plugins	Durable customizations	Cache directories	Environment noise
Build assets (if you build them)	Deterministic deploy	.env files	Secrets risk
Config templates	Repeatability	Database exports (usually)	Large and sensitive

caution

Never commit secrets (API keys, SMTP creds, license keys). Add them via environment variables, server config, or secret managers.

A Practical Repo Layout

Many teams version only what they own:

• wp-content/themes/generatepress-child/
• wp-content/mu-plugins/
• wp-content/plugins/site-features/

What About GeneratePress Elements?

Elements created in the WP admin live in the database. That means they are not automatically versioned.

Practical options:

• Keep small snippets as code (child theme / site plugin) instead of large Hook Elements
• Document each Element (title, location, display rules) and export settings when your workflow supports it
• Treat the database as a deployable artifact only if you have a disciplined migration process

tip

If an Element contains more than a few lines of PHP, move it into versioned code and leave only a thin "call site" in the Element (or remove the Element entirely).

Starter .gitignore

.gitignore (WordPress customization repo)

.DS_Store
node_modules/

# WP uploads and caches
wp-content/uploads/
wp-content/cache/
wp-content/wflogs/

# Environment files
.env
.env.*

Commit Discipline (So History Stays Useful)

Keep commits small and descriptive:

• One feature/fix per commit
• Message explains intent ("why"), not just files changed
• Avoid committing generated artifacts unless you intentionally deploy them

Secrets and Environment Configuration

Common patterns:

• Store secrets in environment variables (server config)
• Commit a template file (example: .env.example) with placeholders
• Document required vars in README.md

Example: README excerpt for required env vars

Required environment variables:
- SMTP_HOST
- SMTP_USER
- SMTP_PASS

caution

If a secret was committed, assume it is compromised. Rotate it, then remove it from Git history using the appropriate tooling.

Workflow: Staging -> Production

flowchart LR
  A[Feature branch] --> B[Review + test]
  B --> C[Merge to main]
  C --> D[Deploy to staging]
  D --> E[Smoke test]
  E --> F[Deploy to production]

Hands-On: Initialize Git for a Child Theme

Initialize a repo and commit a child theme (example)

cd /var/www/example.com/public_html/wp-content/themes/generatepress-child
git init
git status

If you accidentally tracked files you should ignore:

Stop tracking a directory that should be ignored

git rm -r --cached wp-content/uploads
git status

tip

If you are working on a server, keep the repo where you can deploy safely. Many teams keep a separate deploy repo and sync to wp-content/.

Troubleshooting

Symptom	Likely cause	Fix
Repo is huge	Uploads included	Update .gitignore, remove tracked uploads
"Works on staging, fails on prod"	Env-specific config committed	Move config to env vars and document requirements
Merge conflicts in built assets	Assets committed without a build step	Add build pipeline; commit outputs only if needed
Sensitive file shows up in status	Missing ignore rule	Add to .gitignore and remove from index if tracked

Quick Reference Commands

Useful Git commands for day-to-day work

git status
git diff
git log --oneline -n 10

Quick Reference

• Version what you own: child theme + site code
• Exclude uploads, caches, and secrets
• Use a staging-first deployment workflow

What's Next

• Next: Custom REST Endpoints