{"id":1573,"date":"2025-10-30T14:28:14","date_gmt":"2025-10-30T14:28:14","guid":{"rendered":"https:\/\/aki-hamano.blog\/?p=1573"},"modified":"2025-10-30T14:28:14","modified_gmt":"2025-10-30T14:28:14","slug":"how-i-made-my-first-commit-to-wordpress","status":"publish","type":"post","link":"https:\/\/aki-hamano.blog\/en\/2025\/10\/30\/how-i-made-my-first-commit-to-wordpress\/","title":{"rendered":"How I made my first commit to WordPress"},"content":{"rendered":"\n

My first contribution to WordPress development was in May 2020<\/a>. It was to the Gutenberg project, and I have continued contributing ever since. The Gutenberg project’s source code is hosted on GitHub, so I learned various things there, such as how to use git commands, manage branches, and submit pull requests.<\/p>\n\n\n\n

On the other hand, the WordPress core source code is managed using SVN, not Git. Although I was nominated as a core committer in July 2024 and had commit access to the codebase, I had never actually made a commit myself.<\/p>\n\n\n\n

In this article, I would like to explain how I develop for WordPress and how I made my first commit to the WordPress core. Please note that I use a Windows OS machine.<\/p>\n\n\n\n

How I develop<\/h2>\n\n\n\n

Code editor and WSL<\/h3>\n\n\n\n

I use Cursor<\/a> and have installed the WSL plugin in it and connect to various projects through it.<\/p>\n\n\n\n

\"Cursor\"<\/figure>\n\n\n\n

In short, I’m doing almost all of my development within WSL2 (Ubuntu), rather than on the host OS. Based on my experience, it offers better performance than the host OS, allowing for faster installation of npm libraries and project builds. Furthermore, a real Linux environment is running within WSL2, and I can rebuild the environment without affecting the host OS in case any problems arise.<\/p>\n\n\n\n

Within that WSL environment, I have cloned the wordpress-develop repository, which I forked to my own GitHub account<\/a>.<\/p>\n\n\n\n

Node version management tool<\/h3>\n\n\n\n

I use Volta<\/a> as a version management tool for Node.js. I primarily use Node version 22, but for some projects, the scripts may not work if the Node version is too high, so I change the Node version using commands like the following:<\/p>\n\n\n\n

volta install node@20<\/code><\/pre>\n\n\n\n
This command is very convenient because it automatically installs npm, which comes bundled with that Node version.<\/p>\n\n\n\n
Git commands and GitHub commands<\/h3>\n\n\n\n
Although I’m only using very basic commands, I’ve registered the following aliases to help me work more efficiently:<\/p>\n\n\n\n
s  = status         # Show working directory status\nco = checkout       # Switch branches or restore files\nb  = branch         # List, create, or delete branches\nlo = log --oneline  # Show commit history in one line per commit<\/code><\/pre>\n\n\n\n
Furthermore, I frequently use the following GitHub CLI commands to check out, review, and test pull requests locally.<\/p>\n\n\n\n
gh pr checkout {pr_number}<\/code><\/pre>\n\n\n\n
Preparing to commit<\/h2>\n\n\n\n
I’ve submitted patches and pull requests many times before, but they were all committed by other committers. To commit myself, I first needed to create a local working copy of the SVN repository.<\/p>\n\n\n\n
When I asked for advice from the core committers in the Slack channel, many of the committers using Windows told me that they create their SVN copies on the host OS rather than in WSL2.<\/p>\n\n\n\n
It’s possible that installing the Subversion CLI in WSL would allow me to commit to the core from WSL as well. However, to avoid confusion with the GitHub mirror, wordpress-develop<\/code>, I decided to set up my commit environment on the host OS.<\/p>\n\n\n\n
Installing SVN client<\/h3>\n\n\n\n
While I prefer the command-line interface (CLI) over the graphical user interface (GUI) for Git, I’m still unfamiliar with SVN, so I installed TortoiseSVN<\/a>, a Subversion client for Windows. I believe I used this tool in the past when I first published my own plugin to .org, but I haven’t used it much since then, so I probably uninstalled it.<\/p>\n\n\n\n
One important point during installation was enabling the “command line client tools” option, as I might need to use SVN command-line tools in the future:<\/p>\n\n\n\n
\"Install<\/figure>\n\n\n\n
Next, check out the WordPress Trunk according to this document<\/a>. I used the wordpress-svn\/trunk<\/code> directory, also considering the possibility of creating copies of other branches in the future.<\/p>\n\n\n\n
Open the checked-out SVN copy in a code editor. Run svn info<\/code> to confirm that the CLI is working correctly:<\/p>\n\n\n\n
$svn info\n\nPath: .\nWorking Copy Root Path: D:Desktopwp_devwordpress-svntrunk\nURL: https:\/\/develop.svn.wordpress.org\/trunk\nRelative URL: ^\/trunk\nRepository Root: https:\/\/develop.svn.wordpress.org\nRepository UUID: 602fd350-edb4-49c9-b593-d223f7449a82\nRevision: 61089\nNode Kind: directory\nSchedule: normal\nLast Changed Author: wildworks\nLast Changed Rev: 61089\nLast Changed Date: 2025-10-30 20:54:22 +0900 (Thu, 30 Oct 2025)<\/code><\/pre>\n\n\n\n
Also, since I will be using Grunt tasks in the next section, we will run npm install<\/code> here as well.<\/p>\n\n\n\n
Furthermore, I executed the following commands:<\/p>\n\n\n\n