Git Lifecycle: Git commits

last update:

A short guide to writing industry-standard Git commit messages. This information comes from posts and articles about good Git-message writing.

Messages should be strictly specific to the code committed.
Code committed should not be "a big pile" of different work, but targeting a succinct and intact goal and the commit message should reflect that.
Messages should be readable and understandable by people who do not commit to the code base or even write code.
Looking back at the code one year on, you should be able to understand the change and the reason for it.
Before composing a commit message, ask yourself:
- Why did I do this work?
- What changes does this work make?
- Are the changes necessary?
- Do the changes relate to other parts of the code?
- Do the changes relate to an issue, bug, task or story?


[ #: ] type-of-change: [ scope: ] description

...where # is the issue or bug reporting reference from e.g.: JIRA, Bugzilla, etc., and

...type-of-change is one of:

Type	Description
fix	changes to resolve a bug in the codebase
feature	chages to add a new feature to the code base
chore	changes not related to a feature or a bug, but involve modification or updating dependencies
refactor	changes involving refactored code, but do not include refactoring
docs	changes filed to documentation, README.md or markdown
style	changes to coding style in the codebase
test	changes to test files including corrections, bug fixes
performance	changes to improve the applications's performance
ci	changes to CI integration such as in files and scripts
build	changes to files involving build files
revert	reverting to a previous commit

For example:

UI-192: feature: Add cancel button to the dialog.