If you’ve ever changed a theme or plugin, uploaded it, and then wondered, “Wait… what did I just change?” you already understand the problem Git solves. Git keeps your work organized, your teammates unblocked, and your future self grateful.
It’s one of those developer skills that feels intimidating until it clicks. Then you wonder how you ever built anything without it.
In this post, we’ll break down Git in plain English, show how it fits into day-to-day WordPress development, and give you a clean mental model for working confidently, whether you’re solo or collaborating with a team.
What Git is and what it isn’t
Git is a version control system. That means it tracks changes to files over time so you can:
- See what changed and when.
- Understand who changed it (including “you, three weeks ago”).
- Roll back to a previous version if something breaks.
- Work on multiple ideas in parallel without overwriting each other.
Git was created by Linus Torvalds in 2005. The name is an inside joke: “git” is British slang for an unpleasant person. The important part isn’t the trivia. Git became the default language of collaboration in modern software development.
Git is not GitHub. Git is the tool on your computer. GitHub is one popular place to host Git repositories online.
If you’re brand new, think of it like this:
- Git is the camera taking snapshots of your project.
- A repository is the photo album.
- GitHub / GitLab / Bitbucket are places to store and share that album with other people.
The core idea: snapshots, not “file saving”
A common beginner mistake is to treat Git like a magical “undo” button. It’s better than that, but also different.
When you “save” a file, you overwrite it. When you commit in Git, you create a snapshot of your project at that moment, along with a message describing what that snapshot represents.
You don’t commit every time you type a character. You commit when you reach a meaningful checkpoint:
- “Add settings page UI”
- “Fix PHP warning on null meta”
- “Switch query to
WP_Queryto avoid global override”
Over time, you end up with a timeline of your work you can browse, compare, and revert if needed.
That timeline is the real superpower.
Repositories
Git is distributed, meaning your computer has the full history of the project, not just the current files.
That’s different from older centralized systems like SVN, where the server is the “real” source of truth and your local copy is more limited.
In Git, you usually work in two places:
- Local repository (on your machine): where you do most of your daily work
- Remote repository (on a service like GitHub): where your team shares work and runs collaboration workflows
This has a practical benefit: even if the internet is down, you can still commit, branch, diff, and keep moving.
GitHub: more than storage
If Git is the engine, GitHub is the garage with good tools.
A hosted platform like GitHub typically provides:
- Pull requests (collaboration + review)
- Issues (task tracking)
- Release management
- CI/CD automation (via GitHub Actions)
- Security features (dependency alerts, code scanning, secret scanning)
- Team permissions and branch protection
Also worth noting that GitHub isn’t the only place to host Git. Depending on your team or constraints, you might use another popular host like GitLab or Bitbucket. Regardless, the Git fundamentals work cleanly across platforms.
The everyday Git workflow
Most developers repeat a small loop all day:
- Pull the latest changes from the remote
- Create a branch for new work
- Make changes
- Stage them
- Commit them with a good message
- Push the branch to the remote
- Open a pull request
- Merge after review + tests
Here’s what those words actually mean.
Working directory vs staging vs commits
Git has three main “zones” you’ll feel constantly:
- Working directory: the files you’re editing
- Staging area (index): the changes you’ve marked to include in the next commit
- Commit history: the saved snapshots
The staging area is one of the most misunderstood parts of Git, and it’s the feature that makes Git feel “professional.”
It lets you do something like:
- edit five files,
- stage only two of them for one commit (“Refactor sanitization”),
- stage the other three for a second commit (“Update UI copy”),
even though you made the changes in one session.
Branches
A branch is just a movable pointer to a line of commits. That’s the technical definition.
The human definition is simpler: a branch is a safe place to work on something without disturbing everyone else.
Instead of editing directly on main, you create a branch like:
- feature/add-related-posts-block
- fix/php-8-2-deprecations
- chore/update-dependencies
You do your work there. When it’s ready, you merge it back.
Pull requests
A pull request (PR) is a conversation around a set of commits. It’s where:
- Teammates review changes
- Automated tests run
- People ask questions
- Improvements happen before problems ship
Even if you’re a solo developer, PRs are still useful. They force you to summarize what you changed and give you a clean checkpoint with discussion and context.
If you’ve ever stared at code you wrote a month ago and thought, “Why did I do it this way?”, PR descriptions are your future memory.
Git in WordPress projects: what to commit (and what not to)
WordPress adds a twist: a typical site includes a lot of generated files and environment-specific secrets that should never be committed.
Here’s a sane baseline approach:
Commit these
- Custom themes
- Custom plugins
- mu-plugins (if you use them)
- Build tooling (composer.json, package.json, webpack/vite config, etc.)
- Templates, CSS, JS, PHP source files
- Configuration templates
Avoid committing these
/wp-content/uploads/(media files balloon repos and don’t belong in source control)wp-config.php(often contains database credentials and salts)- Cache directories
vendor/node_modules(usually; rely on dependency managers instead)- WordPress core files (in most workflows)
The exact setup depends on how you deploy, but the guiding principle is consistent: Git should track source code and configuration, not runtime state.
If you haven’t used .gitignore before, it’s a file that tells Git what to stop tracking. A typical WordPress .gitignore includes uploads and config secrets. GitHub provides starter templates you can borrow and adjust.
WordPress + Git gets better with a real local environment
If your workflow is “edit on the server,” Git will feel awkward. Not because Git is bad, but because the workflow is fragile.
A stronger setup is:
- Local dev environment (Docker-based, local PHP stack, or managed dev tooling)
- Git repo for the theme/plugin/site code
- Deployment pipeline to staging/production
Tools like WP-CLI also pair nicely with Git because they make repeatable changes easy:
- Database search-replace
- Plugin activation
- Cache flushes
- Generating scaffolds for plugins/themes
Repeatable commands and versioned code mean fewer “how did we do this last time?” moments.
GitHub Actions and automation
Once your code lives in GitHub, you can automate the boring and error-prone parts:
- Run PHP linting and unit tests on every PR
- Run JavaScript builds
- Run WordPress coding standards checks
- Build release zips for plugins
- Deploy to staging when main changes
- Block merges if tests fail
This is what people mean by CI/CD: Continuous Integration and Continuous Deployment.
Even a simple workflow that runs tests can change team behavior in a good way. People stop guessing. The pull request shows green checks or it doesn’t.
Git vs SVN: why Git won
SVN (Apache Subversion) is a centralized version control system that’s still used in some places and works fine for certain workflows. Git became dominant largely because it made branching cheap, merging practical, and local work fast.
In SVN, branching and merging historically carried more friction and social overhead. In Git, branching is lightweight enough that “make a branch” becomes the default move, not a special event.
For WordPress specifically, you may still encounter SVN because parts of the WordPress ecosystem (especially plugin distribution) have long-standing SVN roots. Even then, many developers build day-to-day in Git and mirror releases where needed.
The takeaway isn’t “SVN bad.” It’s simply that Git fits modern collaboration patterns better for most teams.
A mental model that keeps Git simple
If Git starts to feel like a mess of commands, return to these three questions:
- What changed? (git status, git diff)
- What do I want to save as a snapshot? (stage + commit)
- Where should this snapshot live? (local branch vs pushed branch vs merged to main)
Most Git mistakes happen when people move too fast and skip question one.
Where to go next
Once you’re comfortable with the basics, you’ll naturally level up into topics like:
- Rebasing vs merging
- Tags and releases
- Signed commits
- Branch protections and required checks
- Dependency update automation
But don’t rush it. Most working developers use a small slice of Git every day and only reach for advanced tools when needed.
Start with steady habits:
- Commit with intention
- Write messages that make sense
- Treat your main branch like production, because eventually it will be.
One last note on shipping WordPress code smoothly
Git is fantastic at tracking code, but most WordPress headaches show up during deployment: inconsistent environments, missing builds, secrets in the wrong place, “it worked on staging,” and late-night hotfixes nobody can explain the next morning.
A good hosting workflow pairs Git with predictable environments, safe deployments, and a clean path from development to production. If you’re building serious WordPress projects and want that kind of guardrail-heavy setup, Pagely managed WordPress hosting is designed for performance and operational sanity for sites where downtime isn’t an option.
