Git Workflow

To contribute to this project, you must adhere to the feature and pull request git workflow chosen for this project. Additionally, it is recommended that the GitHub Conventions page is read before beginning.

Feature and Pull Request Workflow

Creating Branches

All branches must relate to one or more GitHub issues, detailed here. The branch names must adhere to one of the following formats (depending on the GitHub issue type):

• bug/<bug-name>
• documentation/<documentation-name>
• feature/<feature-name>
• refactor/<refactor-name>

Furthermore, the feature/refactor/bug/documentation name must be hyphenated and describe the issue in a few words.

Making commits

When implementing changes, it is recommended to commit often. Commits should be made at stable stages of the development.

Commits should have informative descriptions, listing the changes which have been made. Additionally, commit messages should be written in the past tense. Following are some examples of good and bad commit descriptions.

👎 Fixed bug 

👍 Fixed NullReferenceException caused by incorrect variable used 

If a bug is noticed in the previous commit, it is ideal to utilise the git amend feature (git commit --amend --no-edit) to ensure the previous commit is a stable state.

Merging

Before creating pull requests, branches should be up to date with the changes introduced by master. It is therefore recommended that the branch owner merges master into their branch with the following commands:

git fetch
git merge origin/master

Do NOT rebase master into your branch.

Creating pull request

Branches should be pull requested into master once the feature is complete. Ensure that the pull request template is filled out completely. Also ensure that any necessary wiki pages associated with the changes are created/updated.