master - releases and hotfixes only. Do not submit PR's to master!
develop - main development branch.
For local branches prepend your messages with feat/ or fix/ (e.g. for a tabs-related fix it would be fix/tabs, feat/date-picker or fix#1000/important-bug). This is necessary to keep local branches visually separated from the public ones.
The master branch keeps the latest stable release plus potentially some cherry-picked hotfixes. All the development should be conducted in local branches (fork of the project).
Do not submit PRs against the master branch. Use the develop one instead.
Checkout a feat/* branch from the develop, then create a pull request to develop.
It's OK to have multiple small commits as you work on your PR - we will let GitHub automatically squash them into a single one before merging.
If fixing a bug:
If you are resolving a certain issue, add closes #<xxx>[,#<yyy>] (, is the related issues' ids) into the PR's description so that GitHub could automatically close the related issue(s) as soon as the respective commits are merged into the master branch (i.e. as soon as a new version of Vuestic UI is out).
Provide detailed description of the bug inside the PR in case the bug is not arranged in the form of a separate issue.
Always link a PR to its related issue (via closes #123).
When you start working on a task - please self-assign the related issue. We don't want a lot of people working simultaneously on the same thing (except when intentional).
For small issues you may push to the develop branch directly while adding closes #123 to the commit message.
For breaking changes add the word BREAKING to PR name, that would allow us to automatically find it before release.
Create a single PR for one issue. If we have several PRs - move all the code into a single PR and close the rest. If one PR covers several issues - either split it in several PRs or mark one of the issues as duplicate.
Make sure to assign an issue to only a single person.