docs: add documentation for lint and commit setup

docs/lint-and-commit-setup/lint-and-commit-setup.md

@@ -0,0 +1,43 @@
+This markdown document provides explanations for how the lint and commit setup works in the project.
+
+![alt text](lint-and-commit-setup-flow-diagram.png)
+
+## Brief overview of git hooks
+- Hooks are named for the event they intercept and use `pre-` or `post-` prefixes to indicate their timing. E.gs are: `pre-commit`, `commit-msg`(after the commit message, but before the commit is created), `pre-push`, and `post-receive` (after successful push).
+
+- Inside any git repo, the hooks are stored in `.git/hooks` directory. The sample hooks can be activated by renaming them and removing the `.sample` extension.
+
+## How does husky work?
+- When we run `npm run prepare`, `husky install` command is executed, which creates a `.husky` directory in the root of the project and sets up the files for managing git hooks in `_` subdirectory. It also sets `git config core.hooksPath .husky` to tell git to look for hooks in the `.husky/_` directory instead of the default `.git/hooks` directory. We can override the default hooks by creating files with the same name as the hook we want to override in the `.husky` directory. For example, if we want to override the `pre-commit` hook, we can create a file named `pre-commit` in the `.husky` directory and add our custom script to it. 
+
+One e.g. commit flow is this:
+```txt
+git commit
+  -> Git notices "pre-commit" should run
+  -> Git looks in core.hooksPath (.husky/_)
+  -> Git executes .husky/_/pre-commit (The command is: . "$(dirname "$0")/h")
+  -> that forwards calls to Husky's  (.husky/_/h) helper script
+  -> Husky's helper runs our real .husky/pre-commit script
+```
+
+## How commiting works in our project?
+- We use a library called `lint-staged` to run linters on the staged files before committing. The configuration for `lint-staged` is defined in the `package.json` file under the `lint-staged` key. It specifies that we want to run `eslint` on all staged JavaScript and TypeScript files.
+
+- Our current pre-commit hook is set up to run `lint-staged` command, which runs `eslint` on the staged files.
+
+- Then, the `commit-msg` hook is set up to run `commitlint` command, which checks the commit message against the defined rules in `commitlint.config.js` file. The rules specify that the commit message should follow the conventional commit format, which includes a type, an optional scope, and a description. If the commit message does not follow the format, the commit will be rejected and an error message will be displayed.
+
+```txt
+git commit
+    ... (the above flow happens)
+    -> `npx lint-staged` is executed in the pre-commit hook
+    -> `lint-staged` looks at the configuration in `package.json` and finds that it needs to run `eslint` on all staged JavaScript and TypeScript files
+    -> `eslint` runs on the staged files and checks for any linting errors
+    -> If there are linting errors, the commit is rejected and an error message is displayed
+    -> If there are no linting errors, the commit proceeds to the next step, which is the `commit-msg` hook
+    -> `npx commitlint --edit $1` is executed in the `commit-msg` hook
+    -> `commitlint` checks the commit message against the rules defined in `commitlint.config.js`
+    -> If the commit message does not follow the conventional commit format, the commit is rejected and an error message is displayed
+    -> If the commit message follows the conventional commit format, the commit is created successfully.
+```
+