When you’re developing in WordPress and creating your own custom plugin or theme, you need to use version control. It makes it easier to keep track of changes in your code and the evolution of your project.
To separate different offshoots of work in your code, you need development branches. How you manage those branches can really make or break your development process.
This way of working with branches is called a workflow. It helps prevent inefficiencies, wasted time, or even broken code that might otherwise occur due to poor branch management or lack of coordination within your team.
I’ve worked with two types of workflow: Git Flow and trunk-based development. I will share my experience with each and how trunk-based development has emerged as a better solution in WordPress development.
Problems with Git Flow
For a long time, I’ve worked with the Git Flow methodology – a setup designed so your main branch consists only of code for new versions, while a separate development branch consists of all the ongoing changes to different features.
This gets complicated when you want to spin off many new lines of work and features from the development branch, and things can get even messier when you create new versions, as this also involves new branches.
As the project progresses, it becomes harder to keep track of where you are and how your plugin development is progressing. Plus, you end up doing more manual checks when merging in development branches.
Also, development branches can sometimes have incomplete code that might accidentally get merged into the main branch.
Typically, Git Flow includes five types of branches: main, develop, feature, release, and hotfix, each serving a different purpose:
- Main: This is production-ready code. It should be clean, error-free, and only merged from tested branches.
- Develop: Runs parallel to main, holding code from various branches. It may include unfinished code and should be thoroughly tested before merging into main.
- Feature: Used when working on new features – probably the most common branch type.
- Release: A pre-production branch. In simpler workflows, this can be skipped, and develop can be used to prep for production instead.
- Hotfix: Created directly from main to fix bugs in production. Once fixed, it’s merged back into both main and develop to prevent recurring issues.
While Git Flow was one of the first structured methods out there, it brings its own complications:
- It can get overly complex.
- Too many branches can cause confusion during development.
- Old feature branches might become outdated and harder to update.
- Merging feature branches into development can trigger conflicts due to incomplete code.
- Where do you run your automated tests – in develop or release?
Ultimately, this workflow might make development more convoluted, leaving teams unsure of where to create new branches or how far along the project is.
Trunk-based development
TBD (trunk-based development) is a workflow built around a single main branch with stable code. From it, subtasks are created in short-lived branches that are deleted after development, automated testing, and code review are complete.
This method is super-efficient for branch management since old branches are deleted regularly. The idea is to integrate different developments more frequently, helping the project evolve with every merge.
Plugin Check (PCP) is a great tool for building WordPress plugins that are standards-compliant. Contributing to it helped me discover the TBD version control workflow that significantly improves resulting plugin quality – it’s more secure, more error-free, and better integrated with automated testing.
Automated testing is mandatory in this workflow.
TBD pairs perfectly with test-driven development (TDD), where tests are written before the code. This allows for early validation during development.
Main benefits of writing tests before coding:
- Improved quality: You’re forced to consider initial requirements and design before writing code.
- Added safety layer: Ensures changes won’t break existing features.
- Less debugging time: Tests push your code to its limits, making it easier to spot issues.
- Better plugin design: Tests highlight potential future issues.
- Easier refactoring: Functionality is verified automatically.
Once your code and tests are ready, it’s time to make a pull request – this is where automated tests kick in to make your code more robust.
In conclusion, TBD has greatly impacted the WordPress ecosystem by making it easier to test during development. This is super-important now that plugins and themes are getting increasingly complex and need automated testing more than ever. TBD is the workflow we use with the Plugin Check plugin, which lets us create a set of automated tests every time we develop something new. That way, our code is way more reliable with each new version.
How do you get started?
Just follow these steps to get it up and running!
- Clean up any old development branches if you had a previous repo. If it’s new, just create one main branch – you can call it trunk or main.
- Coordinate with your team so that for every task, they always create a well-documented issue first. From there, create a branch. GitHub makes it easy with the toolbar on the right. Try to keep tasks small and manageable.
- Set up automated tests for your repo. You can check out the Plugin Check repo for lots of automation examples.
- When you’ve finished development on each branch, create a pull request. This enables you to review new code before it gets merged into the main branch. If you can make it so that at least one or two people review the code before merging it into the main branch, even better.
And this becomes a continuous, repeatable process.
Have you set this up in your plugin development? Do you think it improves your workflow? Let us know in the comments below.
David Pérez is a Hostinger-sponsored WordPress contributor. He has taken the role as Plugin Team contributor and developed the Plugin Check tool that helps thousands of plugin developers around the world.