GitHub Workflow

This page describes our workflow in GitHub. We’ll walk through creating issues, branches and pull requests as well as the different steps a PR goes through. At WP Simple Pay we use GitHub for hosting our remote code repositories, issues & pull requests.

Creating Branches

Every time you work on a new GitHub issue, you must create a dedicated branch. You must never commit directly to the stable or develop branches, unless you have explicit approval from one of our release leads. Once you’ve completed development, you can then use this branch to create a pull request. When you create a new branch, you must make sure to create your branch off the relevant parent branch:

• stable – hotfixes for important issues
• develop – new rocks and features
• release/x.x.x – issues assigned to a specific release (e.g. release/4.15.0)

As an effort in providing more contextual info to our branches, we also use a specific branch naming strategy:

<nickname>/<type>/<issue-number>/<short-description>

• <nickname/shortname>: should be something short that identifies you (from the other team members, e.g. GitHub username).
• <type>: should be one of the following: bug, feature, hotfix, change, enhancement or rock.
• <issue-number>: the number of the issue.
• <short-description>: short but helpful dash-case description of what the branch does. Could be a dash-case version of the issue title, if applicable.

This translates to the following examples:

cristianr/bug/4562/fix-declined-card-message
cristianr/feature/4570/new-payment-methods

Creating Issues

Creating new issues in GitHub is a rather straight-forward process:

1. Select a template that best fits the type of issue – bug, change, or chore (code cleanup).
2. Enter a relevant name for the issue that follows our issue naming convention. The issue should be prefixed with the area or feature the issue affects, followed by a short description of what the issue actually entails. e.g. Form Templates - Fix payment button not working for one time payments or Emails - Add subscription cancelled notification
3. Add the Label for the Area affected by the Issue: component-form-builder, component-emails, etc.
4. Follow the steps in the issue template and fill in the relevant sections.
   • You’ll describe what the issue is about, how it affects our users and how it can be reproduced.
   • If any users reported the issue, add a link to the relevant WordPress.org support forum thread or Help Scout ticket and add the Support label.
   • Add any other applicable labels such as Plugin/Theme Conflict or Good First issue.

Creating Pull Requests

1. Enter a relevant name for the PR that follows our PR naming convention. The PR should be prefixed with the area or feature the issue affects, followed by a short description of what the PR actually entails, e.g. Sitemap - Fix hidden products not included from index or Redirects - Fix Check Redirect modal not closing.
2. Target the right base branch. If the PR is for an issue that’s already been assigned to a release, target the relevant release/x.x.x branch. Otherwise, target develop.
3. Assign yourself to the PR. This allows us to quickly identify the owner of the PR.
4. Fill in all the sections of the PR template. This includes:
   • The issue(s) that the PR fixes.
   • A more detailed description that explains what exactly that the PR does.
   • Detailed testing instructions for the PR reviewers.