2016-10-14 14:25:04 +03:00
|
|
|
## Development Workflow
|
|
|
|
|
|
|
|
|
|
### Small Feature Development
|
|
|
|
|
|
2017-05-18 21:21:33 +03:00
|
|
|
Contributors who have write access to the repository will practice continuous
|
2016-10-14 14:25:04 +03:00
|
|
|
delivery (CD as known from now on in this document).
|
|
|
|
|
|
|
|
|
|
We will define CD in this document as a method of developing a feature per commit
|
|
|
|
|
with an encapsulating test that proves that the functionality is working, the
|
|
|
|
|
contributor will test their code locally and if all is passing will push to *master*.
|
|
|
|
|
|
|
|
|
|
For contributors that do not have write access, follow the same conventions but
|
|
|
|
|
open a Pull Request instead.
|
|
|
|
|
|
|
|
|
|
### Large changesets
|
|
|
|
|
|
|
|
|
|
When larger changes need to be made, or the work that is carried out spans multiple
|
|
|
|
|
components / services of the application at the same time a single commit will
|
|
|
|
|
not suffice.
|
|
|
|
|
|
|
|
|
|
In this scenario, the contributor should open a pull request instead.
|
|
|
|
|
|
|
|
|
|
## Commit messages
|
|
|
|
|
|
2017-05-18 21:21:33 +03:00
|
|
|
Follow [Git blessed](http://chris.beams.io/posts/git-commit/) and [Conventional Commits](https://conventionalcommits.org)
|
2016-10-14 14:25:04 +03:00
|
|
|
|
|
|
|
|
1. Separate subject from body with a blank line
|
|
|
|
|
2. Limit the subject line to 50 characters
|
|
|
|
|
3. Capitalize the subject line
|
|
|
|
|
4. Do not end the subject line with a period
|
|
|
|
|
5. Use the imperative mood in the subject line
|
|
|
|
|
6. Wrap the body at 72 characters
|
|
|
|
|
7. Use the body to explain what and why vs. how
|
