Git Workflow

Branching Strategy

There are only two branches on Famous/engine, "master" and "develop". Local work should be done on private forks. If collaboration between two or more teammembers is needed, they should each have their own forks and be continually rebasing off of each other. When ready, submit pull requests to "develop" for a code review. Once code has been reviewed and accepted it will be merged into "develop".

Code Review

Code must meet the following standards in order to be passed:

• It must work
  • No breaking code, features must work, fixes must fix
• It is something we conceptually want in the codebase
• Test are included
• Lints
• Doesn't break existing tests
• Commits properly restructured

Commit Structure

Pull requests should be kept to the most minimal amount of commits possible. This means that it is very likely you will have to squash your commits down into their logical grouping. Every commit must start with one of the reserved words so that it can be parsed by the changelog tool. The reserved words are:

• feat: Feature
• breaks: Breaking Change
• fix: Bug Fix
• perf: Performance Improvement
• docs: Documentation Changes
• tests: Testing
• examples: Feature
• clean: Organizing & cleaning

If these are insufficient, file a github issue to this repository to suggest making changes.

Try and keep your pull requests as small as possible. That said, there will be times where a single pull request will have multiple commits.