--------------COMMIT GUIDE-----------------
Overview:
Commit should follow the proper format so that new contributers in the project can understand it well
Commit are important add any automation changes or release notes as long as commit is meaningful
It saves time during code review when commit history is proper and meaningful
How to Guide:
1. Treat commit as building block of types like: fix, refactor, feat, docs, etc.
2. One commit one change, idea is to have each commit for a logic change
3. Make each commit small and atomic
4. any commit that we build should have corresponding test cases related to the changes
Format: <type> (<scope>)(optional):<space> <description>(lowercase, total title length < 72)
<blank line>
<body> (sentence case, each line length < 80)
<blank line>
<footer> (footer format -> <token>: <value>)
concepts:
1. type: provides context of commit i.e intent of change that was made. always in lowercase
ex.
a. feat => new feature
b. fix => bux fix
c. refactor => refactoring code
d. revert => reverting one or more commits
e. docs => changes releted to documentation
f. test => adding or refactoring tests
g. chore => non-feature related cleanup tasks e.g: Regerating generated code
i. ci => related to CI/CD
2. scope: this is optional field. will always be in lowercase. is used to TAG package or module in code repo which
will get affected after change. it must be inside parenthesis i.e ().
3. description: this is the short summary for the code changes. will always be in lowercase, shouldn't end with period
guide:
1. Use the imperative mood without period for description -> "fix bug" and not "fixed bug" or "fixes bug" or "fixing bug"
2. trick to this is alway read description as "git pull to <description message>"
3. this convention matches as per git and github we can verify it when git generates commit at the time of merge commit and
revert commit
4. body: body is used to write additional details to commit. It can consist of any number of lines or paragraphs to describe the changes added.
the body should focus on explaining what and why changes are made rather than how.
the body should follow proper grammer, punctuation, cases and should end sentence with period.
5. footer: footers are recomended to be used to link commits to issues or pull requests. footers follow format <token>: <value>
ex. Refer: FLDG-123.
commitlint: https: