Skip to content

5. Git workflow

Jump to bottom
Dominik Schilling edited this page Jan 21, 2016 · 9 revisions

We use the git flow branching model.

Important: Whenever you have to merge a branch, use the --no-ff flag.
This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.

  • The master branch represents latest version released in WordPress.org's plugin directory. HEAD of this branch is always equal to last tagged release. The masterbranch is a protected branch.

  • The develop branch represents the cutting edge version. This is probably the one you want to fork from and base your patch on. This is the default GitHub branch.

  • Release branches: When a new version is going to be released, we'll branch from develop to release/x.y.z. This marks version x.y.z code freeze. Only blocking or major bug fixes will be merged to these branches. They represent beta and release candidates.

  • Hotfix branches: When one or several critical issues are found on current released version, we'll branch from master to hotfix/x.y.z+1. If an issue was found on an older version, we'll branch from tags/x.y.z to hotfix/x.y.z+1.

  • Fix or feature branches: Proposed new features and bug fixes should live in their own branch. Use the following naming convention: if a GitHub issue exists for this feature/bugfix, the branch will be named ISSUEID-keywords where ISSUEID is the corresponding GitHub issue ID. If a GitHub issue doesn't exist, branch will be named keywords. These branches will be merged in:

    • hotfix/x.y.z if the change is a fix for a released version,
    • release/x.y.z if the change is a fix for a beta or release candidate,
    • develop for all other cases.
Clone this wiki locally