All code you commit and submit by pull-request should follow these simple guidelines.
When creating a branch for your work, always use git flow convention.
Our flavoured flow, comprehend following prefixes:
feat/- everything that is not a bug should be created with this prefix;fix/- from the git flow point of view, this is just another way to call feat/. It's helpful to have such a differentiation to prioritize reviews better.release/- needed to prepare the release.
Follow Conventional Commits standard.
- Open the pull request giving a title following Conventional Commits. Keep the title short (~50 characters). Always try to give a scope to the title.
Following this convention will help keep the repository in order and create sleek changelogs.
- Try to fill the pull request template as closely as possible. Provide a short description that answers these questions:
- "how this pull request will change the code?"
- "what is the purpose of these changes?"
Take the opporutnity to reflect on your learnings and share them with everyone else.
-
For any task, try to provide a way to test its results; it would greatly help the QA process.
-
Assign the pull request to yourself.
-
Upon approval, you are in charge of merging the code back. It's crucial to own the code we create and ensure it is released. If you wish your code is merged upon approval, please, specify it in the pull request description.
-
Upon merge (ndr. squash and merge), remember to delete the merged working branch; let's keep a clean repository.
Within this project, we follow a Test-Driven Development (TDD) approach.