Branching model and pull requests

Branching model

Both master and development branches are locked and cannot be directly modified by anyone (except administrators, aka me). We will follow git-flow, meaning master will only receive commits whenever a new gnomy version is ready for release.

A slight alteration to git-flow was made for the initial code base: core/* branches. These serve the purpose to add code and/or refactor the project structure, in a way that will affect most or all of the existing/future features. These changes might not necessarily be final, as in you can't do changes to the involved parts in the future, but must act as a foundation. The main example is the branch core/db_model, where the initial database model (including dependencies between tables) was created. Even though the schemes for different modules can (and probably will) change over time, these initial code base allowed development to take a more integral approach from the very beggining of the app lifecycle.

Pull requests

All pull requests must target development branch and have to fulfill the next requirements:

• Include a description of the changes it makes.
• Reference affected issues, closing them if needed (See Linking a pull request to an issue).
• Travis CI is automatically trigger on pull requests (see more about tests), running the contents of the test package, so you should check that those unit tests work before creating your pull request.

Additionally, pull requests require 1 approving review (currently, mine). This number might change in the future if the project gets enough collaborators.