diff --git a/Git/docs/Commits_Convention.md b/Git/docs/Commits_Convention.md
new file mode 100644
index 0000000..1aa1a23
--- /dev/null
+++ b/Git/docs/Commits_Convention.md
@@ -0,0 +1,31 @@
+# Conventional Commits
+
+To improve your commits and ensure they cover everything, the secret lies not only in the prefix but in the full structure of the message and the mindset you use to divide your work. The Conventional Commits standard is very powerful, but to make it truly useful, you should leverage the body and footer of the message, as well as expand the available types.
+
+To organize the types of changes, you can use this reference:
+
+| Type | Purpose | Example |
+| :--- | :--- | :--- |
+| `feat` | A new feature for the user. | `feat(auth): add google oauth2 login` |
+| `fix` | Bug fix. | `fix(ui): resolve overlap in mobile menu` |
+| `docs` | Changes only to documentation. | `docs(readme): add installation steps` |
+| `style` | Visual or formatting changes that do not affect logic (whitespace, commas). | `style(css): update primary button padding` |
+| `refactor` | Code change that neither fixes a bug nor adds a feature. | `refactor(db): optimize user query` |
+| `perf` | Code change to improve performance. | `perf(images): implement lazy loading` |
+| `test` | Adding missing tests or correcting existing ones. | `test(api): add unit tests for user controller` |
+| `build` | Changes that affect the build system or external dependencies. | `build(npm): update react to v18` |
+| `ci` | Changes to CI configuration files and scripts (GitHub Actions, Jenkins). | `ci(github): add lint check to pr workflow` |
+| `chore` | Routine tasks that do not modify production code. | `chore(git): add .gitignore for vscode` |
+| `revert` | Revert a previous commit. | `revert: undo feat(api): add user auth` |
+
+The golden rule is to make **atomic commits**: one commit should do one thing. If you fixed a bug and also happened to change a color and update the README, don't use a single commit with an ambiguous prefix; make three separate commits.
+
+For more complex messages, use the full three-part structure:
+
+### Commit Structure
+
+The header is what you already know: `<type>(<scope>): <short description>`. The description should be written in the **imperative mood** (e.g., "add" instead of "added" or "adds"), as if you were giving an order to the code.
+
+The body is an optional paragraph separated from the header by a blank line. This is where you explain the **why** of the change and not the **how**. The "how" is already visible in the code; the "why" is what the team needs to know months later to understand the technical decision.
+
+The footer is the final section where ticket references or breaking changes are noted. If a change breaks backward compatibility, you must start the footer with `BREAKING CHANGE:`, followed by a description of the change and how to migrate. It is also the ideal place to close issues using keywords like `Closes #123` or `Fixes #456`.
diff --git a/Git/docs/GITHUB_ACTIONS.md b/Git/docs/GITHUB_ACTIONS.md
new file mode 100644
index 0000000..bf899d3
--- /dev/null
+++ b/Git/docs/GITHUB_ACTIONS.md
@@ -0,0 +1,9 @@
+# CI/CD
+
+### 1. Workflow
+
+### 2. Automatitaion of my test
+
+### 3. Automatitaion of my gh-pages
+
+##### **References**
diff --git a/Git/docs/SSH_KEY.md b/Git/docs/SSH_KEY.md
new file mode 100644
index 0000000..77ddd20
--- /dev/null
+++ b/Git/docs/SSH_KEY.md
@@ -0,0 +1,90 @@
+# SSH Configuration for GitHub
+
+SSH uses asymmetric cryptography, which is more secure than password authentication because it allows you to prove your identity without ever sending your private credentials over the network. This process relies on a key pair: a public key, which you share with GitHub, and a private key, which stays securely on your local machine in `~/.ssh`.
+
+The email address used during key generation acts as a comment or label. While it doesn't affect the encryption, it helps you identify which key is which when managing multiple keys in your GitHub settings.
+
+## Step 1: Generate Your SSH Keys
+
+Open your terminal and run the following command. Replace the email with the one associated with your GitHub account.
+
+```bash
+ssh-keygen -t ed25519 -C "your_email@example.com"
+```
+
+When prompted to "Enter a file in which to save the key," press Enter to accept the default location. You can also add a passphrase for an extra layer of security.
+
+## Step 2: Add Your Key to the SSH Agent
+
+The SSH agent manages your keys so you don't have to type your passphrase every time you use Git.
+
+```bash
+# Start the ssh-agent in the background
+eval "$(ssh-agent -s)"
+
+# Add your private key to the agent
+ssh-add ~/.ssh/id_ed25519
+```
+
+## Step 3: Add the Public Key to GitHub
+
+You must provide GitHub with your public key to authorize your machine.
+
+1. Copy your public key to your clipboard:
+   ```bash
+   cat ~/.ssh/id_ed25519.pub
+   ```
+2. Log in to GitHub and go to **Settings** > **SSH and GPG keys**.
+3. Click **New SSH key**, give it a descriptive title (e.g., "Work Laptop"), and paste the key into the box.
+4. Click **Add SSH key**.
+
+## Step 4: Configure Multiple Accounts
+
+If you have separate accounts (e.g., personal and university), you cannot use the same key for both. Generate a second key with a different name (e.g., `id_ed25519_uni`) and add it to your second GitHub account. Then, create or edit your `~/.ssh/config` file to route the traffic correctly:
+
+```bash
+# Personal account
+Host github.com-per
+    Hostname github.com
+    User git
+    PreferredAuthentications publickey
+    IdentityFile ~/.ssh/id_ed25519
+
+# University account
+Host github.com-uni
+    Hostname github.com
+    User git
+    PreferredAuthentications publickey
+    IdentityFile ~/.ssh/id_ed25519_uni
+```
+
+## Step 5: Using Multiple Accounts with Git
+
+When you use a config file with custom hosts, you must change the URL when cloning a repository. Instead of using `github.com`, use the alias you defined in the config file.
+
+To clone using your personal account:
+
+```bash
+git clone git@github.com-per:username/repo-name.git
+```
+
+To clone using your university account:
+
+```bash
+git clone git@github.com-uni:uni-username/repo-name.git
+```
+
+## Step 6: Test Your Connection
+
+To verify that everything is working, run the following command:
+
+```bash
+ssh -T git@github.com
+```
+
+If successful, you will see a message like: `Hi username! You've successfully authenticated, but GitHub does not provide shell access.`
+
+##### **References**
+
+- [How to set up ssh keys for github](https://dev.to/taujor/how-to-set-up-ssh-for-github-on-linux-a-step-by-step-guide-1jmh)
+- [https://www.geeksforgeeks.org/computer-networks/introduction-to-ssh-secure-shell-keys/]