How I commit to WordPress core

After WordCamp US 2024, some core committers have started sharing their WordPress contribution workflows. Since mine appears to be a bit different from the other ones posted so far, I figured I’d follow suit. So here’s how I commit to WordPress!

The following sections cover everything that comes to mind right now. If there’s more in the future or something changes, I’ll try to update this post accordingy.

Separate repositories

I use separate folders for the checkouts of the Git repository and the SVN repository. The Git repository points to both official mirrors.

For daily work, I use Git. Be it for the local development environment, running tests, applying patches, or submitting pull requests.

Only for committing I take an actual patch file or PR and apply it in the SVN repository and then commit the change.

Local development

On my work laptop I cannot use Docker, so I can’t use the built-in development environment. Instead I use Local for running trunk locally. I symlinked the default site it creates to my Git checkout, which worked surprisingly well.

Aliases

Over the years my workflow hasn’t changed that much, so for the most frequently used commands I created aliases and put them in my dotfiles.

Aliases for Subversion:

alias sup="svn up --ignore-externals"
alias vcsclean="find . -name \"*.orig\" -delete && find . -name \"*.rej\" -delete"
alias svnclean="svn revert -R * && vcsclean && sup"Code language: Bash (bash)

For Git I have a ton more aliases, but nowadays I only use a handful, like git squash, git amend, git undo, or git patch.

I might add the gh-patch alias Joe uses, as it is faster than using npm run grunt patch, especially since the latter always tries to first install npm dependencies, which is a bit annoying.

Committing

If I am committing on the command line, I use svn ci to open my default editor, which is nano. There I write the commit message, save the changes, and close the editor to push the commit.

I check the commit message guidelines frequently, which I think every core committer should do. Sometimes I think a custom linter in a pre-commit hook or so would be cool.

GUI

Most of the time I actually don’t use svn on the command line, but instead use Cornerstone, which as a GUI Subversion client for Mac. I think it was originally recommended to me by my friend and fellow core committer Dominik.

A graphical user interface provides this extra safety when dealing with more complex scenarios like adding or removing files, backporting commits, or changing file properties. On the command line it would easy to miss some things, but with a UI it’s much easier to see everything at a glance.

Similarly, I use Tower for Git.