Ako/ Add general doc for ts and git (deriv-com#5763)

* doc/ add TS general doc

* docs/ add git general doc

* docs/ commit message guide lines

Co-authored-by: Carol Sachdeva <58209918+carol-binary@users.noreply.github.com>

docs/Typescript/README.md

@@ -0,0 +1,56 @@
+# Typescript Guidelines
+
+## General
+
+### Use tuples for fixed length arrays
+
+```typescript jsx
+let marks: number[] = [1, 2, 3];
+```
+
+You can use the above ‘marks’ array to store different number of items in different places of the same script. TS is not gonna restrict you as long as you provide all the values with the correct defined data type.
+
+```typescript jsx
+let marks: number[] = [1, 2, 3];
+marks = []; // success
+marks = [1]; // success
+marks = [1, 2, 3, 4, 5]; // success
+```
+
+However this can lead to nasty logical errors in cases where the array length is a constant. To avoid these you should use array as a tuple, whenever the size should be a fixed size. Tuple is a properly defined array with each of the expecting value’s data type.
+
+```typescript jsx
+let marks: [number, number] = [1, 2]; // tuple of 2 number values
+marks = [10, 20]; // success
+marks = [1]; // syntax error
+marks = [1, 2, 3, 4, 5]; // syntax error
+```
+
+### Use correct data type annotation ( avoid ‘any’ )
+
+Data type annotation is one of the advantages you have when coding in TS, while JS defines data types in the run time. defining data types in TS saves you from weird run time errors that can occur by mistakes. Do not use ‘any’ keyword when you know what type of data your variable’s gonna hold. It is recommended that you always define the data type whenever you declare a new variable.
+
+```typescript jsx
+name: string = 'Hello';
+value: number = 50;
+isCorrect: boolean = false;
+```
+
+### Use type aliases in repetitive data types
+
+Assume that you have multiple variables/ objects in your script which all follow the same structure of data types.
+
+```typescript jsx
+let man: { name: string; age: number } = { name = 'john', age = 30 };
+let woman: { name: string; age: number } = { name = 'Anne', age = 32 };
+```
+
+to avoid this redundant chunks of type declarations and to re-use types, you can use type aliases.
+
+```typescript jsx
+type Details = { name: string; age: number }; // defining type alias
+let man: Details = { name = 'john', age = 30 }; // using type alias
+let woman: Details = { name = 'Anne', age = 32 };
+```
+
+The additional benefit of using a type alias is, your intention of defining the data is now clearly visible.

docs/git/README.md

@@ -0,0 +1,70 @@
+# Git
+
+## General
+
+### Adequately configure the commit authorship
+
+You should at least set your name and email address correctly. As commits are communications tools, knowing who made a specific change can help you in the future.
+
+#### Configure your Git username/email
+
+You typically configure your global username and email address after installing Git. However, you can do so now if you missed that step or want to make changes. After you set your global configuration, repository-specific configuration is optional.
+
+Git configuration works the same across Windows, macOS, and Linux.
+
+##### To set your global username/email configuration:
+
+1. Open the command line.
+2. Set your username:
+   git config --global user.name "FIRST_NAME LAST_NAME"
+3. Set your email address:
+   git config --global user.email "MY_NAME@example.com"
+
+### Branch Naming
+
+We agreed to have this convention for branch naming in the entire frontend repositories
+
+`{OWNER_NAME}/{TASK_ID}/{BRANCH_TITLE}`
+
+-   `OWNER_NAME`: is the developer name that working on it
+
+-   `TASK_ID`: would refer to id of the task in the task manager app which is currently Redmine.
+
+-   `BRANCH_TITLE`: branch name that would be a feature, bugfix or hotfix
+
+Example:
+
+`ako/54641/proof_of_ownership`
+
+### Commit only related work
+
+Do you know what S from [SOLID](https://en.wikipedia.org/wiki/SOLID) stands for? Yeah, [Single Responsibility Principle](https://en.wikipedia.org/wiki/Single-responsibility_principle). You can apply this principle for commits, not only to the code. You should commit the least amount of lines that make sense together.
+
+This practice helps when digging into the codebase, like when using `git log` or `git blame`.
+
+### Commit message guidelines
+
+We have a precise rules over how our git commit messages can be formatted. This leads to more **readable messages** that are easy to follow when looking through the **project history**.
+
+Each commit message will consists of **type** and **subject**:
+
+```sh
+<type>|<...other_types>: <subject>
+```
+
+#### Commit Type
+
+Must be one of the following:
+
+-   **build**: Changes that affect the build system or external dependencies (example scopes: gatsby config, gatsby browser, gatsby node, or gatsby ssr)
+-   **chores**: Add or Changes on packages or external dependencies
+-   **ci**: Changes to our CI configuration files and scripts (example scopes: Docker, nginx conf)
+-   **docs**: Documentation only changes
+-   **feat**: A new feature
+-   **fix**: A bug fix
+-   **perf**: A code change that improves performance
+-   **refactor**: A code change that neither fixes a bug nor adds a feature
+-   **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+-   **text**: Adding text or updating text only
+-   **empty**: Rare cases for re-deploying when deployment server is down
+-   **revert**: A commit reverts a previous commit