05. Conventions

🏍️ Branch Management

🔷 main(master)

- branch for actual deployment

🔷 develop

- branch for development 
- should be fully ready for the next release

🔷 feature

- branch to develop a function on
- takes a `feature/[issue number]` form as its name
- will be merged to the develop branch once the function development completes

🔷 hotfix

- branch for hotfix
- only to troubleshoot sudden issues that occur in the deployed version.

🔷 release

- branch for release preparation
- starts from develop, and merges into main once everything is prepared
- commits only to do with bug fixes

🏍️ Commit Messages

Udacity Git Commit Message Style will be followed

🔷 Type

- feat: A new feature
- fix: A bug fix
- docs: Changes to documentation
- style: Formatting, missing semi colons, etc; no code change
- refactor: Refactoring production code
- test: Adding tests, refactoring test; no production code change
- chore: Updating build tasks, package manager configs, etc; no production code change

🔷 Structure

- type: Subject

- body

- footer

🔷 details

1. subject
- should be no greater than 50 characters.
- should begin with a capital letter and do not end with a period.
- use an imperative tone to describe what a commit does, rather than what it did
2. body
- is used to explain the 'what and why' of a commit, not the how.
- should limit the length of each line to no more than 72 characters.
3. footer (optional)
- is used to reference issue tracker IDs.

🏍️ Code Styles

ktlint has been applied to the project

🔷 how it works

1. Typing gradlew ktlintCheck on the command line will enable an automatic check for Kotlin conventions

2. Nonetheless, pre-commit is set for this project. Therefore, ktlintCheck is invoked at any time before composing a commit message with git commit