We roughly follow the git flow branching model. All bug fixes and new feature work is done using new branches that are then brought into
develop using pull requests.
trunk branch represents the latest version released in production.
develop branch represents the cutting edge version. Usually, this is what you want to fork and base your feature branch on. This is the default GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ branch.
Feature or fix branch names should use the pattern
issue/ISSUEID-description where the
ISSUEID is the Github issue number. For example, if the issue number is 1000 and the issue is related to an editor crash, an appropriate branch name would be
If there is no Github issue, you can use prefixes like
fix/. Some examples are
As you commit code to these branches, don’t tag the issue number in the individual commit messages as it pollutes the pull request and makes it messier. Just attach the issue number to the final pull request. Before you submit your final pull request, make sure all your branches are up to date with
Release branches are branched from
release/x.x while we iterate release versions. Pull requests can target specific release branches but should be limited to bug fixes or patches only, no features or new implementation. The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team will subsequently merge the release branch back to
develop to keep it up to date.
All released versions are tagged with the version number. For example, the 12.2 production release will be tagged as