Before you start
- Install Git client
- Make sure your git client reflects your name and email address as per your GitHub account.
git config --global user.name "John Doe" git config --global user.email firstname.lastname@example.org
Creating a feature or bugfix
- Fork the repository
- Make sure your develop branch is fully up to date with the upstream
- Branch from the head of the develop branch
- If at all possible, name your branch according to the issue that caused you to create it
- Make your changes, commit/push
- If develop moves on, rebase your branch on develop. Do not merge develop to the branch.
Submitting a feature or bugfix
- When ready, rebase your branch in interactive mode and squash all the commits to one commit.
- Make sure the commit message in the one commit -
- Is written in the present tense and imperative mood e.g. "Force widget factor to 7"
- Don't exceed 50 characters for the first line
- Leave a blank line
- Optionally include any other descriptive text you feel qualifies the reason for the change
- Preferably include reference (not URL) to the issue that caused you to make this change e.g. PNDA-8
- Push this to your branch and open a PR
- GitHub will take the title of the commit as the PR name, do not modify this
- In the description, include any descriptive text you feel qualifies the reason for the change
- Note validation that has been carried out
- Do not fill the description with design discussion and so on - describe the code and what it does
Force widget factor to 7
PNDA-1234: Widget factors other than 7 cause all kinds of problems. Introduced new WidgetFactorFactory to generate sevens.
Responding to feedback on the PR
- Keep discussion on the PR if possible and record outcome of side discussions if not
- If the PR has been closed, do not delete or rebase your branch before re-opening the PR
- Do not close PRs and open new PRs for the same work
- Ensure the PR commit history and relationship with develop remains sane
- If develop moves on, rebase branch on develop
- If rework of existing changes is required it usually makes sense to rebase and squash to one commit
- If the additional work is purely additive, an additional commit is often all that's necessary
Given the difficulty of N-way merging on a single location in a single file on GitHub, we've decided to make modifications to the CHANGELOG a Maintainer activity. Therefore, omit these from the PR and we'll make the change after merging.