Design patterns

Github

Specification of the patterns used for the code versioning platform used - GitHub.

Branches

The branch name must follow the structure: <type>/<scope>

Possible types:

1. feat: are used when developing a new feature or enhancement which has the potential of a development lifespan longer than a single deployment. When starting development, the deployment in which this feature will be released may not be known;
2. fix: differ from feature branches only semantically. They will be created when there is a bug on the live site that should be fixed and merged into the next deployment. For that reason, a bug branch typically will not last longer than one deployment cycle;
3. upgrade: comes from the need to act upon an undesired state of a live production version. Additionally, sometimes, because of the urgency, a hotfix is not required to be be pushed during a scheduled deployment. Due to these requirements, a upgrade branch is always branched from a tagged stable branch.

Scope: Name of functionality or enhancement, based on the issue. Can have up to three words, in lower case, with a hyphen as the word separator.

Commits

The commit name must follow the structure: <branch type>(<branch scope>): <message>

Message: should be clear and meaningful. Lowercase, short (50 chars or less) summary, using imperative, like "fix bug" and not "fixed bug" or "fixes bug" - this convention matches up with commit messages generated by commands like git merge and git revert.

Pull Requests

Name: Branch name

Body: Use this template:

### Issue Name
**What I did:**
- First thing I did;
- Second thing I did.

**How to test:**
1. First thing to do;
2. Second thing to do.