If you develop WordPress plugins with GitHub, you may be surprised when your first plugin is approved for the WordPress.org Plugin Directory.

Instead of asking for your GitHub repository, WordPress.org gives you something different:

https://plugins.svn.wordpress.org/your-plugin/

It’s an SVN repository.

That naturally raises a question:

Should a WordPress plugin use GitHub or SVN?

For many WordPress plugin developers, the answer is:

Both.

GitHub and WordPress.org SVN solve different problems.

GitHub is an excellent home for developing and collaborating on your plugin. WordPress.org SVN is the publishing system used to distribute approved plugins through the official WordPress Plugin Directory.

WordPress itself makes this distinction very clearly: its Plugin Directory requires the provided Subversion repository, while GitHub is one of the options it recommends for open-source collaboration and development.

Understanding the role of each makes the entire WordPress plugin release process much easier.

What Is GitHub Used for in WordPress Plugin Development?

GitHub is built around Git, a distributed version-control system.

For a WordPress plugin developer, a GitHub repository might contain:

my-plugin/
├── .github/
├── src/
├── includes/
├── assets/
├── languages/
├── tests/
├── composer.json
├── package.json
├── my-plugin.php
├── README.md
└── CHANGELOG.md

GitHub can serve as the development home for your project.

You can use it for things such as:

• source control;
• branches;
• pull requests;
• issue tracking;
• collaboration;
• development history;
• code review;
• release notes;
• GitHub Releases;
• and downloadable source code.

Your Git repository can contain the history of how your plugin was built.

That’s exactly the kind of work Git is good at.

What Is WordPress.org SVN Used For?

WordPress.org uses Subversion (SVN) for plugins distributed through the official Plugin Directory.

Once your plugin passes review, WordPress.org grants you access to a dedicated SVN repository. After you publish the plugin files and readme through that repository, the plugin can appear in the Plugin Directory.

The repository normally contains:

your-plugin/
│
├── assets/
├── tags/
└── trunk/

WordPress defines these areas broadly as:

assets/
 ↓
Plugin Directory artwork

trunk/
 ↓
Current plugin code

tags/
 ↓
Published plugin versions

The assets directory holds things such as Plugin Directory icons, banners and screenshots. Plugin code belongs directly in trunk, while formal releases should be created under tags.

That makes SVN much more closely connected to publishing and distribution on WordPress.org.

The Biggest Difference: Development vs. Release

This is the distinction every WordPress plugin developer should understand.

A simple way to think about it is:

 GITHUB

 Build the plugin
 │
 │
 Develop features
 Fix bugs
 Review code
 Collaborate
 Maintain history
 │
 ▼
 RELEASE READY
 │
 ▼
 WORDPRESS SVN

 Prepare release
 Update trunk
 Create version tag
 Commit release
 Verify publication
 │
 ▼
 WORDPRESS.ORG

WordPress explicitly describes its SVN repository and Plugin Directory infrastructure as a release repository rather than a development repository.

It even warns developers not to push every small development change to SVN because each push causes WordPress.org to rebuild the plugin’s ZIP files.

That’s fundamentally different from the way many developers work with GitHub.

The important row is:

Publishes plugin to WordPress.org: GitHub — No. WordPress SVN — Yes.

If your goal is distribution through the official WordPress.org Plugin Directory, maintaining a project on GitHub does not replace the WordPress.org SVN publishing step. WordPress states that its Plugin Directory requires use of the provided Subversion repository.

Can I Publish a WordPress.org Plugin Directly From GitHub?

Not simply by pushing your project to GitHub.

Your GitHub repository and your WordPress.org repository are separate publishing destinations.

You might have:

GitHub
github.com/company/my-plugin

and:

WordPress.org SVN
plugins.svn.wordpress.org/my-plugin/

The GitHub repository does not automatically become the WordPress.org Plugin Directory repository.

Your approved WordPress.org plugin still has its SVN repository.

This is why many developers eventually need a process for moving a finished release from their development environment into WordPress SVN.

Git Tags and SVN Tags Are Not the Same Thing

This is another source of confusion.

Suppose your new plugin version is:

2.5.0

On GitHub, you might create a Git tag:

v2.5.0

and use it for a GitHub Release.

In WordPress SVN, the release might be:

tags/2.5.0/

These may represent the same conceptual software release, but they’re not the same technical object.

You have two repositories:

 VERSION 2.5.0
 │
 ┌──────┴──────┐
 ▼ ▼
 GitHub WordPress.org
 │ │
 ▼ ▼
 Git Tag SVN Tag
 v2.5.0 tags/2.5.0/

WordPress recommends creating version-numbered SVN tags and creating those releases from trunk.

So don’t assume creating a GitHub tag has automatically created your WordPress.org release.

It hasn’t.

README.md vs. readme.txt

GitHub and WordPress.org also have different documentation conventions.

GitHub projects commonly use:

README.md

WordPress.org plugins traditionally use:

readme.txt

That means a well-maintained plugin may legitimately contain both.

Think of them as two presentations of the same product:

README.md
 │
 └── GitHub project presentation


readme.txt
 │
 └── WordPress.org Plugin Directory information

Your GitHub README might focus on developers, source code, installation from Git, contributing and development information.

Your WordPress readme.txt can contain the Plugin Directory description, installation information, FAQ, screenshots, changelog, compatibility information and Stable Tag.

The WordPress.org Plugin Directory derives information from the plugin files, readme.txt, and SVN repository.

WordPress SVN Tags vs. GitHub Releases

GitHub Releases are useful for distributing versions of your software directly through GitHub.

A release might contain:

WordPress Plugin v2.5.0

What's New
• Added feature A
• Improved feature B
• Fixed issue C

Download:
my-plugin-v2.5.0.zip

That’s useful for developers, customers or users who obtain the software through GitHub.

But your WordPress.org users don’t get their Plugin Directory update from that GitHub Release.

Their update ultimately comes through the WordPress.org distribution system.

So you can publish the same release in two places:

 PLUGIN 2.5.0
 │
 ┌────────────┴────────────┐
 │ │
 ▼ ▼
 GitHub WordPress.org
 │ │
 Git tag v2.5.0 SVN tags/2.5.0
 │ │
 GitHub Release Plugin Directory
 │ │
 ▼ ▼
 GitHub audience WordPress users

That’s not unnecessary duplication.

They’re two different distribution channels.

Should My GitHub Repository Match WordPress SVN Exactly?

Not necessarily.

This is an important architectural decision.

Your GitHub repository might contain development resources that should never ship inside the production WordPress plugin:

.github/
tests/
development-scripts/
design-files/
build-tools/
node_modules/
.gitignore

Your production plugin may contain only:

my-plugin.php
includes/
assets/
languages/
readme.txt

And the WordPress SVN repository has another layer:

assets/
tags/
trunk/

GITHUB SOURCE
 │
 ▼
BUILD / PACKAGE
 │
 ▼
PRODUCTION PLUGIN
 │
 ├───────────────┐
 ▼ ▼
 GitHub WordPress SVN
 Release │
 trunk/
 tags/
 assets/

That’s often healthier than blindly copying an entire Git repository into WordPress SVN.

WordPress explicitly advises developers not to put files into SVN that they aren’t prepared to deploy to users and says compressed ZIP files should not be uploaded to the SVN repository.

Why Not Just Develop in WordPress SVN?

Technically, SVN is a version-control system.

But WordPress doesn’t want its Plugin Directory SVN infrastructure used like your everyday Git development repository.

Every push can cause WordPress.org to regenerate plugin ZIPs. WordPress therefore asks developers to push finished changes rather than every small development commit.

So this:

fix typo
commit

change button
commit

test idea
commit

revert idea
commit

change CSS
commit

is perfectly ordinary development behavior in Git.

It isn’t how you should treat the WordPress.org release repository.

Instead:

GitHub

20 development commits
 ↓
Testing
 ↓
Release approved
 ↓
Plugin 2.5.0
 ↓
ONE DELIBERATE RELEASE
 ↓
WordPress SVN

That’s a much cleaner separation.

Why Keep GitHub If WordPress.org Already Has SVN?

Because GitHub provides an entirely different layer around your software project.

Your GitHub repository can become the public technical home for your plugin.

Developers can:

• inspect the source;
• submit issues;
• contribute changes;
• review history;
• create pull requests;
• follow development;
• and download releases.

WordPress itself specifically identifies GitHub as an option for open-source collaboration, while separately requiring SVN for the Plugin Directory.

So there isn’t really a conflict between the two.

A useful model is:

GitHub manages the life of the code.

WordPress SVN manages the WordPress.org release of the code.

What If My Plugin Is Only on GitHub?

That’s completely reasonable if you don’t intend to distribute the plugin through WordPress.org.

You can maintain a WordPress plugin entirely on GitHub and distribute it yourself.

But if you want the plugin to appear in the official WordPress.org Plugin Directory, you’ll enter the WordPress.org submission process and, after approval, publish it using the SVN repository WordPress provides.

That’s when SVN becomes part of your release workflow.

What If My Plugin Is Only on WordPress.org?

That’s possible too.

You aren’t required to maintain a GitHub repository simply because you’re publishing a WordPress plugin.

For a very small plugin, you may decide that WordPress.org is all you need.

But as a plugin grows, GitHub can provide valuable development capabilities that the WordPress SVN release repository isn’t designed to replace.

This becomes particularly valuable when you have:

multiple developers
 +
feature development
 +
issue tracking
 +
testing
 +
release history
 +
community contributions

At that point, separating development from distribution becomes increasingly useful.

The Best Workflow for WordPress Plugin Developers

For many developers, I would recommend this architecture:

┌─────────────────────────────────────┐
│ GITHUB │
│ │
│ Development │
│ Source control │
│ Branches │
│ Pull requests │
│ Issues │
│ Testing │
│ Collaboration │
└──────────────────┬──────────────────┘
 │
 │ Release Ready
 ▼
┌─────────────────────────────────────┐
│ PRODUCTION BUILD │
│ │
│ Clean plugin package │
│ Correct version │
│ Correct documentation │
│ Validated release │
└──────────────┬───────────┬──────────┘
 │ │
 ▼ ▼
 ┌────────────┐ ┌────────────────┐
 │ GITHUB │ │ WORDPRESS SVN │
 │ │ │ │
 │ Git tag │ │ Update trunk │
 │ Release │ │ Create tag │
 │ Changelog │ │ Commit │
 └────────────┘ └────────┬───────┘
 │
 ▼
 WORDPRESS.ORG
 PLUGIN DIRECTORY

Now each system has a clear responsibility.

The Problem: You’re Maintaining Two Publishing Systems

This architecture is clean, but it introduces another problem.

You now have to coordinate them.

For version 2.5.0, you may need to ensure:

Plugin PHP
Version: 2.5.0

WordPress readme.txt
Stable tag: 2.5.0

WordPress SVN
tags/2.5.0/

GitHub
Tag: v2.5.0

GitHub README
Current version information

GitHub Changelog
2.5.0 release notes

GitHub Release
v2.5.0

And they all need to describe the same release.

That’s where a release that looks simple starts becoming surprisingly easy to get wrong.

One Release, Two Publishing Engines

This is the model we built WordPress Plugin Publisher around.

Instead of pretending WordPress.org SVN and GitHub are the same thing, Publisher treats them as separate publishing engines.

That’s important.

WordPress.org has its own requirements:

WordPress.org
 │
 ├── SVN working copy
 ├── trunk
 ├── tags
 ├── directory artwork
 ├── readme.txt
 ├── WordPress.org credentials
 └── remote verification

GitHub has another:

GitHub
 │
 ├── Git repository
 ├── README.md
 ├── changelog
 ├── Git tag
 ├── GitHub Release
 └── GitHub authentication

Trying to force both into one generic publishing process can create problems.

Instead, Publisher gives each destination its own workflow.

WordPress.org Workspace

For WordPress.org, Publisher guides the release through:

CREATE RELEASE
 ↓
PREPARE REPOSITORY
 ↓
PUBLISHING INTELLIGENCE
 ↓
PUBLISH RELEASE
 ↓
VERIFY

Publisher works with the WordPress.org SVN repository, prepares trunk, creates the version tag, preserves or updates directory artwork as appropriate, checks publishing readiness, commits the release and verifies the result.

GitHub Workspace

GitHub gets its own publishing workflow.

The same completed plugin release can be prepared for its GitHub repository, with its GitHub-specific documentation, changelog, tag and release.

That means you don’t have to pretend:

SVN = Git

because it doesn’t.

Instead:

 ONE PLUGIN
 │
 ONE RELEASE
 │
 ┌────────┴────────┐
 ▼ ▼
 WORDPRESS.ORG GITHUB
 WORKSPACE WORKSPACE
 │ │
 SVN Engine Git Engine
 │ │
 ▼ ▼
 WordPress.org GitHub

That’s a much better mental model for maintaining a plugin in both ecosystems.

SVN vs GitHub: Which Should You Choose?

If you’re asking specifically which one to use for developing a WordPress plugin:

GitHub is generally the better fit for modern development and collaboration.

If you’re asking which one to use for publishing an approved plugin to the WordPress.org Plugin Directory:

WordPress.org SVN is required.

And if you’re asking what we’d recommend for a serious plugin that’s both developed publicly and distributed through WordPress.org:

Use both.

Give each system the job it’s good at.

GitHub for Development. SVN for WordPress.org. Publisher Between Them.

That’s the architecture in one sentence:

Develop with GitHub. Publish to WordPress.org with SVN. Use WordPress Plugin Publisher to manage the release between them.

You shouldn’t have to choose between a modern Git development workflow and publishing your plugin through the official WordPress ecosystem.

Use GitHub to build.

Use WordPress.org to distribute.

And make the publishing layer between them predictable.

Ready to simplify your WordPress plugin releases?

WordPress Plugin Publisher for macOS

Publish WordPress.org SVN and GitHub releases from one dedicated application.

7-day free trial. $69/year thereafter.

Explore WordPress Plugin Publisher