added new docs for devOps

absolute-beginners/devops-beginner/git-and-github/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Git & GitHub",
+  "position": 6,
+  "link": {
+    "type": "generated-index",
+    "description": "Go beyond simple commits. Learn how to use Git to automate deployments, protect your production environment, and manage infrastructure through code. Discover how to leverage GitHub's powerful features to collaborate effectively, automate workflows, and enhance your DevOps practices."
+  }
+}

absolute-beginners/devops-beginner/git-and-github/branching-strategies.mdx

@@ -0,0 +1,92 @@
+---
+sidebar_position: 2
+title: "Branching Strategies: Organizing the Chaos"
+sidebar_label: "2. Branching Strategies"
+description: "Compare GitFlow, Trunk-Based Development, and GitHub Flow to find the best fit for your DevOps pipeline."
+---
+
+A **Branching Strategy** is a set of rules that defines when and how code is moved from a developer's laptop to the production server. If everyone pushes directly to the `main` branch, the site will break every 5 minutes. 
+
+We need a "Traffic System" to ensure only tested, high-quality code reaches our users.
+
+## 1. Trunk-Based Development (The High-Speed Choice)
+
+In **Trunk-Based Development**, all developers work on a single branch (the "Trunk" or `main`). They make small, frequent updates and merge them multiple times a day.
+
+```mermaid
+gitGraph
+    commit id: "Initial"
+    commit id: "Build"
+    branch feature-1
+    checkout feature-1
+    commit id: "Fix-A"
+    checkout main
+    merge feature-1
+    branch feature-2
+    checkout feature-2
+    commit id: "Fix-B"
+    checkout main
+    merge feature-2
+    commit id: "Deploy-v1.1"
+```
+
+* **Best for:** Senior teams with **Strong Automated Testing**.
+* **Why it's DevOps-friendly:** It prevents "Merge Hell" (where two people change the same file and can't fix it later) and allows for **Continuous Integration (CI)**.
+
+## 2. GitFlow (The Structured Choice)
+
+**GitFlow** is a more complex, "Industrial Level" strategy used by large teams. It uses specific branches for different purposes.
+
+| Branch Name | Purpose |
+| :--- | :--- |
+| `main` | **Production Ready.** Only contains stable, released code. |
+| `develop` | **Integration.** Where features meet to be tested together. |
+| `feature/*` | **New Work.** Where individual tasks are built (e.g., `feature/login-ui`). |
+| `release/*` | **Polishing.** Final bug fixes before a big version launch. |
+| `hotfix/*` | **Emergency.** Quick fixes for bugs currently live on the site. |
+
+### The Flow of Code:
+
+$$Feature \rightarrow Develop \rightarrow Release \rightarrow Main$$
+
+* **Best for:** Large teams with **Complex Release Cycles**.
+* **Why it's DevOps-friendly:** It provides a clear structure for managing different stages of development and allows for **Versioning** (e.g., v1.0, v1.1).
+
+## 3. GitHub Flow (The Modern Standard)
+
+This is the strategy we often use for **CodeHarborHub** open-source projects. It is simpler than GitFlow but safer than pure Trunk-based.
+
+1.  **Create a Branch:** Give it a descriptive name (e.g., `update-readme`).
+2.  **Add Commits:** Save your work.
+3.  **Open a Pull Request (PR):** Ask for a "Peer Review" and let the CI tests run.
+4.  **Discuss & Review:** Other developers suggest changes.
+5.  **Merge & Deploy:** Once the green checkmark appears, merge to `main` and deploy.
+
+## Comparing the Strategies
+
+| Strategy | Speed | Risk | Complexity | Recommended For |
+| :--- | :--- | :--- | :--- | :--- |
+| **Trunk-Based** | Blazing Fast | High | Low | Startups / Daily Deploys |
+| **GitHub Flow** | Balanced | Medium | Medium | Web Apps / SaaS |
+| **GitFlow** | Slower | Very Low | High | Banks / Medical Software |
+
+## DevOps Best Practice: Protected Branches
+
+Regardless of the strategy you choose, a DevOps engineer **never** allows direct pushes to `main`.
+
+In GitHub, we use **Branch Protection Rules**:
+
+* **Require a Pull Request:** No one can merge without a review.
+* **Require Status Checks:** The "Merge" button stays grey until the **Docker Build** and **Unit Tests** pass.
+* **Require Signed Commits:** Ensures the code actually came from a verified team member.
+
+## Summary Checklist
+
+* [x] I can explain why pushing directly to `main` is dangerous.
+* [x] I understand that **Trunk-Based** development requires great automated tests.
+* [x] I know that **GitFlow** is best for complex, versioned releases.
+* [x] I understand the 5-step process of **GitHub Flow**.
+
+:::info Note
+If your team is small (2-3 people), start with **GitHub Flow**. It provides the perfect balance of speed and safety without the headache of managing 5 different branch types\!
+:::

absolute-beginners/devops-beginner/git-and-github/git-for-devops.mdx

@@ -0,0 +1,84 @@
+---
+sidebar_position: 1
+title: "Git: The DevOps Backbone"
+sidebar_label: "1. Git for DevOps"
+description: "Learn why Git is the starting point for every automation pipeline and how it manages more than just source code."
+---
+
+In your early coding days, you used Git to keep track of your `index.js` or `style.css`. In DevOps, we use Git to manage **everything**:
+* **Infrastructure:** Your AWS server settings (Terraform/CloudFormation).
+* **Configuration:** Your environment variables and API keys (Encrypted).
+* **Pipelines:** The scripts that build and deploy your app (GitHub Actions YAML).
+* **Containers:** The blueprints for your environment (Dockerfiles).
+
+## 1. The "Control Tower" Analogy
+
+Think of a busy airport. 
+* The **Planes** are your application updates.
+* The **Runway** is your Production Server.
+* **Git is the Control Tower.** Nothing lands on the runway unless the Control Tower (Git) gives the green light. If a pilot (Developer) tries to land without permission, the system blocks them. If a plane crashes (A bug is deployed), the Control Tower can "Roll back" the runway to a safe state instantly.
+
+## 2. Git as an Automation Trigger
+
+In a manual world, you finish code and then manually upload it to a server. In a DevOps world, the moment you `git push`, a chain reaction starts.
+
+```mermaid
+graph LR
+    A[💻 Developer Push] --> B{🐙 GitHub}
+    B --> C[🧪 Run Tests]
+    C --> D[🐳 Build Docker Image]
+    D --> E[🚀 Deploy to AWS/Azure]
+
+    style B fill:#f96,stroke:#333,stroke-width:2px,color:#000
+    style C fill:#9cf,stroke:#333,stroke-width:2px,color:#000
+    style D fill:#fc9,stroke:#333,stroke-width:2px,color:#000
+    style E fill:#c9f,stroke:#333,stroke-width:2px,color:#000
+```
+
+### The "Git-Flow" Logic:
+
+We use specific events in Git to trigger different actions:
+
+1.  **Push to `feature` branch:** Triggers Unit Tests.
+2.  **Pull Request to `main`:** Triggers Integration Tests and Peer Review.
+3.  **Merge to `main`:** Triggers the final Deployment to the live website.
+
+## 3. Audit Trails: The "Who, What, When"
+
+One of the biggest requirements in "Industrial Level" DevOps is **Accountability**. If the **CodeHarborHub** website goes down at 2:00 AM, we don't guess what happened. We check the Git Log.
+
+$$Change\_Log = \text{Author} + \text{Timestamp} + \text{Commit\_Hash} + \text{Diff}$$
+
+Because every change to our infrastructure is committed to Git, we have a perfect "Time Machine." We can see exactly which line of code broke the server and revert it in seconds using:
+`git revert <commit_hash>`
+
+## 4. Collaboration at Scale
+
+DevOps is about breaking down silos between Developers and Operations. Git is the "Meeting Room" where this happens.
+
+* **Developers** write the app code.
+* **Operations** write the Dockerfiles and Kubernetes manifests.
+* They both collaborate on the **same repository**, ensuring that the environment matches the code.
+
+## Essential DevOps Git Commands
+
+While you know `commit` and `push`, these are the "Power User" commands for DevOps:
+
+| Command | Why DevOps use it |
+| :--- | :--- |
+| `git diff` | To see exactly what configuration changed before deploying. |
+| `git log --graph` | To visualize how different features are merging into production. |
+| `git tag -a v1.0` | To mark a specific "Release" point in time for the servers. |
+| `git stash` | To quickly clear the workspace when a production hotfix is needed. |
+| `git cherry-pick` | To grab a specific bug fix from one branch and apply it to another. |
+
+## Summary Checklist
+
+  * [x] I understand that Git manages **Infrastructure** as well as **Code**.
+  * [x] I know that a `git push` is often the trigger for a CI/CD pipeline.
+  * [x] I understand how Git provides an audit trail for troubleshooting.
+  * [x] I can explain why "Everything as Code" starts with Git.
+
+:::info The "GitOps" Secret
+The ultimate goal of DevOps is **GitOps**. This means the state of your production server is *always* an exact reflection of what is in your Git repository. If you change a value in Git, the server changes itself automatically\!
+:::

absolute-beginners/devops-beginner/git-and-github/git-hooks-automation.mdx

@@ -0,0 +1,86 @@
+---
+sidebar_position: 3
+title: "Git Hooks: The Automated Gatekeepers"
+sidebar_label: "3. Git Hooks Automation"
+description: "Learn how to use pre-commit and pre-push hooks to ensure only high-quality code leaves your machine."
+---
+
+Have you ever committed code only to realize 5 minutes later that you left a `console.log` or a syntax error in the file? **Git Hooks** prevent these "silly mistakes" by running checks locally on your computer.
+
+## 1. How Git Hooks Work
+
+Inside every Git repository, there is a hidden folder called `.git/hooks`. This folder contains "Template" scripts for every stage of the Git lifecycle.
+
+```mermaid
+graph TD
+    A[Developer types: git commit] --> B{Pre-commit Hook}
+    B -- "Fail (Bugs found)" --> C[Commit Rejected]
+    B -- "Pass (Clean code)" --> D[Commit Successful]
+    D --> E[Pre-push Hook]
+    E -- "Tests Fail" --> F[Push Blocked]
+    E -- "Tests Pass" --> G[Code sent to GitHub]
+```
+
+### The "Gatekeeper" Logic:
+
+If a script in the `hooks` folder returns an **Error**, Git will stop the action immediately. For example, if your pre-commit hook runs a linter and finds a formatting issue, it will return a non-zero exit code, and Git will reject the commit. This forces you to fix the issue before it can be saved in your Git history.
+
+## 2. The Two Most Important Hooks
+
+As a DevOps engineer, you will focus on these two:
+
+### A. Pre-commit (The Linter)
+
+This runs the moment you type `git commit` but **before** the commit message is saved.
+
+* **Job:** Check for formatting (Prettier), syntax errors (ESLint), or "Secret Leaks" (like accidentally committing your AWS Password\!).
+* **Benefit:** Your Git history stays clean and professional.
+
+### B. Pre-push (The Tester)
+
+This runs when you type `git push`.
+
+* **Job:** Run your **Unit Tests**.
+* **Benefit:** Ensures that you never break the "Main" build on GitHub because you forgot to run tests locally.
+
+## The Mathematics of Prevention
+
+The cost of fixing a bug increases the further it travels from the developer's laptop.
+
+$$Cost\_of\_Fix = \text{Local} < \text{GitHub} < \text{Staging} < \text{Production}$$
+
+By using Git Hooks, we catch errors at the **Local** stage, saving hours of debugging time and server costs.
+
+## 3. Professional Tooling: "Husky"
+
+Manually managing scripts in `.git/hooks` is difficult because that folder is not shared with your team. For **CodeHarborHub** projects, we use a tool called **Husky**.
+
+Husky makes it easy to share hooks across your whole team via your `package.json`.
+
+### How to set up Husky:
+
+1.  **Install:** `npm install husky --save-dev`
+2.  **Initialize:** `npx husky install`
+3.  **Add a Hook:**
+    ```bash
+    npx husky add .husky/pre-commit "npm run lint"
+    ```
+
+Now, every time a developer on your team tries to commit, Husky will automatically run the linter!
+
+## 4. Best Practices
+
+1.  **Keep them Fast:** A pre-commit hook shouldn't take more than 5-10 seconds. If it's too slow, developers will get frustrated and skip it.
+2.  **Don't Over-automate:** Use pre-commit for "Small" things (Linting) and pre-push for "Big" things (Testing).
+3.  **Never Commit Secrets:** Use a hook like `gitleaks` to scan your code for passwords before they ever leave your machine.
+
+## Summary Checklist
+
+* [x] I know that Git Hooks live in the `.git/hooks` folder.
+* [x] I understand that a "Non-zero" exit code stops the Git action.
+* [x] I can explain the difference between **pre-commit** and **pre-push**.
+* [x] I know how to use **Husky** to share hooks with my team.
+
+:::warning The "Skip" Button
+You can skip hooks using `git commit --no-verify`. Use this **ONLY** in extreme emergencies. If you skip hooks, you are bypassing the safety net of your project\!
+:::