Using Git in WordPress Development: From .gitignore to CI/CD Pipelines

Learn how to implement Git for WordPress development, including version control, deployment workflows, branching strategies, and team collaboration tips tailored for WordPress projects.

Every WordPress developer has a version-control horror story. A plugin update that broke checkout on a Friday afternoon. A “quick fix” edited straight into the live theme that nobody can undo. A staging site that quietly stopped matching production months ago.

Git is how you stop living like that. Not because it’s magic, but because it gives you a record of every change and a calm way to move code between your laptop, staging, and the server.

This guide walks the whole path: setting up a repository, writing a .gitignore that actually fits WordPress, picking a branching model you’ll stick with, and getting to automated deploys without over-engineering the thing.

Table of Contents

• Why Version Control is Non-Negotiable for WordPress
• Initializing Your Git Repository for WordPress
• Crafting the Perfect WordPress .gitignore
• Choosing Your Branching Model: Gitflow vs. GitHub Flow vs. Others
• Handling Themes, Plugins, and Core Updates in Git
• Deployment Workflows: From Simple Pulls to CI/CD Pipelines
• Effective Team Collaboration with Git & WordPress
• Navigating Merge Conflicts in WordPress Projects
• Conclusion

Why Version Control is Non-Negotiable for WordPress

WordPress makes it easy to edit code in places you’ll regret later, straight in the admin or straight on the server. Git pulls that back into something you can reason about. Here’s what you get:

• A full history: Every change is recorded, so you can see what shipped and roll back the moment something breaks.
• Real collaboration: More than one person can work on the same site without emailing zip files or overwriting each other.
• Predictable deployment: Moving code from development to staging to production becomes a repeatable step instead of a nervous copy-paste.
• Accountability: You can see who changed what and why, which is worth a lot when you’re debugging at 11pm.

Initializing Your Git Repository for WordPress

Starting a repo is the easy part. Whether it’s a brand-new site or one that’s been live for years, it begins the same way, in your project folder:

git init

The decision that matters comes next: what you actually track. Don’t version the whole WordPress install. Track the code you write, your custom theme and plugins, and let a dependency manager like Composer handle the rest. That one boundary keeps the repo clean for years.

Crafting the Perfect WordPress .gitignore

Your .gitignore is where you draw that boundary. It keeps secrets out of the repo and stops you from committing thousands of files you don’t own. Here’s a solid starting point for a standard WordPress project:

# WordPress core files
/wp-admin/
/wp-includes/
# Core configuration file
wp-config.php
# User uploads and dynamic content
/wp-content/uploads/
# Plugin and theme build artifacts (e.g., minified files, cache)
*.min.js
*.min.css
cache/
node_modules/
# Composer vendor directory
/vendor/
# OS generated files
.DS_Store
Thumbs.db

The one line you can’t get wrong is wp-config.php. It holds your database credentials and secret keys, so it should never land in Git. Adjust the rest to your setup; a Bedrock or Composer-managed site looks different from a classic install.

Choosing Your Branching Model: Gitflow vs. GitHub Flow vs. Others

A branching model is just an agreement about where work happens and how it reaches production. Three common ones:

• Gitflow: Long-lived main and develop branches, plus dedicated branches for features, releases, and hotfixes. It fits projects with scheduled releases and separate dev, staging, and production environments.
• GitHub Flow: One main branch that’s always deployable, with short-lived feature branches merged in through pull requests. It suits continuous deployment and smaller teams.
• Something in between: Most WordPress work lives here. If you’re mainly shipping theme and plugin changes, a simple feature-branch flow off main is usually enough.

Be honest about your scale. Gitflow gives you structure, but it’s a lot of ceremony for a two-person team. Pick the smallest model that fits, and add complexity only when the project earns it.

Handling Themes, Plugins, and Core Updates in Git

The trick with WordPress is separating the code you own from the code you merely use:

• Your custom code: Track your themes, plugins, and functions.php tweaks. This is the work Git exists to protect.
• Everything else: Let Composer or WP-CLI manage WordPress core and third-party plugins. Committing files you don’t maintain just creates noise and messy update conflicts later.

Handle core updates as a managed step, not a commit. Your repository tracks what you built and how it’s wired together, while the platform underneath it stays a dependency you pull in.

Deployment Workflows: From Simple Pulls to CI/CD Pipelines

Deployment is a spectrum, and you don’t have to start at the automated end:

• Manual pulls: For a small site, SSH in and run a git pull. It’s not fancy, but it’s honest and it works.
• Git hooks: A post-receive hook can deploy automatically when you push, checking out the code and running follow-up tasks like clearing caches.
• CI/CD pipelines: Tools like GitHub Actions or GitLab CI can test, build, and deploy for you, only promoting code to staging or production after the checks pass.

Here’s a minimal post-receive hook that deploys on push:

#!/bin/bash
GIT_WORK_TREE=/var/www/your-wordpress-site git checkout -f
# Clear WordPress cache or trigger other post-deployment tasks here

Start with the pull. Reach for hooks or a pipeline when doing it by hand starts to hurt, not before.

Effective Team Collaboration with Git & WordPress

Once more than one person touches the code, Git becomes about communication as much as version control:

• Pull requests: Open one for every feature or fix. It gives your team a place to review the change before it hits main.
• Code reviews: Make review the default, not a favor. It’s the cheapest way to catch bugs and keep the codebase consistent.
• Clear commits: Write commit messages a teammate can read in six months. Keep shared docs current so nobody’s guessing.
• Conflict protocols: Agree on how you’ll handle conflicts, especially in generated CSS/JS or database changes. Merging from main often keeps branches from drifting too far apart.

Navigating Merge Conflicts in WordPress Projects

Conflicts aren’t a sign you did something wrong. They just mean two people changed the same lines. Here’s how to keep them small:

• Merge often: Pull main into your feature branch regularly. Small, frequent merges beat one giant painful one.
• Read the markers: Learn to read Git’s conflict markers. A visual tool like GitKraken helps, but the command line is enough once it clicks.
• Talk it out: For a tangled conflict, ask the other person. They know why their side changed, and two minutes of conversation beats guessing.

Conclusion

Git isn’t really about version control. It’s about working without fear, knowing you can always see what changed and always get back to a working state.

Start small. Initialize a repo, write a .gitignore that fits, pick the simplest branching model that works, and automate deploys only when doing it by hand gets old. Do that, and those horror stories stop being yours.