GitHub Flow

Clones, Branches, and Pull Requests

** Read more about GitHub Flow here

Create a clone of the repo. Create a fork only if you're trying to be experimental.
Create a new branch from 'develop' to work on an issue.
Name the branch using the issue name or number
Immediately publish the branch to the repo. This communicates to the team that you're working on an issue, keeps others from stepping on your toes.
Push changes up to the published branch frequently, daily.
Build & test the branch locally before making a Pull Request. Use QtCreator or your preferred build tools. Import a test pattern & create a layout. If no problems, make a Pull Request. We can provide a test pattern, just ask.
Don’t “Hold” a Pull Request Until the Job is “Done”. Don't make monster Pull Requests - break it down as much as possible and make PRs as small as possible. Multiple PR's per day is fine.

** Notes:

We've recently implemented a Rolling Release versioning method with Pre-Releases created from feature branches, and Releases created weekly.
Currently we work from 'develop' branch to create feature branches. Our move to continuous deployment Rolling Releases means that we should work from 'master'. We'll make this change from 'develop' to 'master' soon.