Git Branching Strategies for WordPress Projects

A consistent branching strategy makes collaboration smoother and deployments safer. For WordPress projects — themes, plugins, or full-site repositories — two strategies work well: GitHub Flow for simple continuous delivery, and a simplified Gitflow for projects with distinct staging and production environments.

Problem: How do you manage multiple developers working on the same WordPress codebase without overwriting each other's changes or deploying untested code?

Solution: Adopt a branching strategy — GitHub Flow for smaller teams (one main branch plus short-lived feature branches) or Git Flow for projects with scheduled releases (main, develop, release, and hotfix branches).

GitHub Flow (simple, one production branch):

# main is always deployable
git checkout -b feature/custom-header
# ... make changes, commit ...
git push origin feature/custom-header
# Open a Pull Request → review → merge to main → deploy

Simplified Gitflow (separate staging and production):

# Permanent branches
# main     — production
# develop  — staging / integration

# Start a new feature from develop
git checkout develop
git checkout -b feature/woo-custom-checkout

# Merge feature back into develop when done
git checkout develop
git merge --no-ff feature/woo-custom-checkout
git branch -d feature/woo-custom-checkout

# Release to production
git checkout main
git merge --no-ff develop
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin main --tags

Useful one-liners for day-to-day work:

# List all branches (local and remote)
git branch -a

# Delete a remote branch
git push origin --delete feature/old-branch

# Sync your fork with upstream
git remote add upstream https://github.com/original/repo.git
git fetch upstream
git merge upstream/main

NOTE: Commit wp-config.php only if all sensitive values are read from environment variables. Never commit passwords, API keys, or salts. Add wp-config.php to .gitignore and keep a wp-config-sample.php in the repo instead.