Commit Standards is an easy methodology to make git commit messages more useful. It provides an easy set of rules for creating an informative git commit history, which makes it easier to write automated tools on top of.
Enforcing this method will help with keeping track of "whats" and "whys" of changes that are made to a software through its development life cycle. This convention helps by describing the features, fixes, and breaking changes made in commit messages.
The commit message should be structured as follows
<type of change >: < description of "whats" >
[ body - description of "whys" ]
[ optional footer ]
The commit is composed of following components
1. fix: a commit of the type fix patches a bug in your codebase. If this fix comes with breaking changes then optional footer must be set to BREAKING CHANGE
2. feat: a commit of the type feat introduces a new feature to the codebase.
3. test: a commit of the type test introduces addition of tests into the application. Commit message must consist of which tests are added.
4. refactor : a commit of type refactor introduces refactor / optimization in the code.
refactor: drop support for Node 6
Node app's module dependencies aren't compatible with node v6 anymore
Commit message with no breaking change, with description of what has changed and why
refactor: correct spelling of CHANGELOG and Update Readme.md
Readme has been updated with info of all the new features added into the application in previous commit.
fix: install coreutils in alpine image at build time
alpine comes with busybox image in which many of the coreutils command are present but only with basic functionality so adding coreutils and glibc to container image before building the application.