codeharborhub · ajay-dhangar · Apr 10, 2026 · Apr 8, 2026
@@ -0,0 +1,105 @@
+---
+title: "Branching and Merging"
+sidebar_label: "6. Branching & Merging"
+sidebar_position: 6
+description: "Learn how to work on multiple features simultaneously using Git branches and how to safely merge them. This guide will explain the concept of branching, how to create and switch between branches, and best practices for merging changes back into the main branch. Whether you're adding a new feature or fixing a bug, understanding branching and merging is essential for effective collaboration and project management."
+tags: ["git", "branching", "merging", "version control", "beginner guide"]
+keywords: ["git", "branching", "merging", "version control", "beginner guide"]
+---
+
+In a professional environment like **CodeHarborHub**, we never work directly on the "Live" code (the `main` branch). Instead, we use **Branches**.
+
+A branch is essentially a **Parallel Universe**. You can build a new feature, experiment with a new design, or fix a bug in a separate space without affecting the main project.
+
+## The Branching Workflow
+
+Imagine you are building a website. The `main` branch is the version users see. You want to add a "Dark Mode."
+
+1.  **Create a Branch:** You step into a parallel universe called `feat-dark-mode`.
+2.  **Work:** You write your CSS and JS. The `main` branch remains untouched and stable.
+3.  **Merge:** Once the dark mode is perfect, you bring those changes back into the `main` universe.
+
+## Step 1: Creating and Switching
+
+You can create a branch and move into it using these commands:
+
+<Tabs>
+<TabItem value="standard" label="The 2-Step Way" default>
+
+```bash
+# Create the branch
+git branch feat-dark-mode
+
+# Switch to the branch
+git checkout feat-dark-mode
+```
+
+</TabItem>
+<TabItem value="pro" label="The Pro Way (1-Step)">
+
+```bash
+# Create and switch immediately
+git checkout -b feat-dark-mode
+```
+
+</TabItem>
+</Tabs>
+
+## Step 2: Merging Changes
+
+Once your work in the branch is finished and committed, it’s time to merge it back to the `main` branch. Here’s how you do it:
+
+**1. Switch back to the destination (Main):**
+
+```bash
+git checkout main
+```
+
+**2. Pull the changes in:**
+
+```bash
+git merge feat-dark-mode
+```
+
+**3. Cleanup (Optional):**
+Since the feature is now part of `main`, you can delete the temporary branch:
+
+```bash
+git branch -d feat-dark-mode
+```
+
+## The Logic of Merging
+
+```mermaid
+graph LR
+    A[Commit 1: Main] --> B[Commit 2: Main]
+    B --> C[Branch: feat-dark-mode]
+    C --> D[Commit 3: Dark Mode CSS]
+    B --> E[Commit 4: Main Hotfix]
+    D --> F{Merge}
+    E --> F
+    F --> G[Commit 5: Final Project]
+```
+
+## Handling Merge Conflicts
+
+Sometimes, Git gets confused. If you changed line 10 in `main` and your friend changed line 10 in `feat-dark-mode`, Git won't know which one to keep. This is a **Merge Conflict**.
+
+**How to fix it:**
+
+1.  Open the file in **VS Code**.
+2.  You will see markers: `<<<<<<< HEAD` (Your version) and `>>>>>>> branch-name` (Their version).
+3.  Delete the version you don't want and remove the markers.
+4.  `git add` the file and `git commit` to finish the merge.
+
+## Industrial Best Practices
+
+| Rule | Why? |
+| :--- | :--- |
+| **Descriptive Names** | Use `feat/login-ui` or `fix/header-logo` so others know what the branch is for. |
+| **Keep Branches Small** | Don't build five features in one branch. One branch = One task. |
+| **Pull Before Merge** | Always run `git pull origin main` before merging to ensure you have the latest team updates. |
+
+:::info
+Not sure what branch you are on? Run `git branch`. The one with the asterisk (`*`) and highlighted in green is your current "Parallel Universe."
+:::
@@ -0,0 +1,92 @@
+---
+title: "Cloning and Forking"
+sidebar_label: "9. Cloning & Forking"
+sidebar_position: 9
+description: "Learn how to download existing projects and create your own copies of open-source repositories to start contributing. This is the essential first step in your journey to becoming a proficient GitHub user and open-source contributor."
+tags: ["git", "github", "cloning", "forking", "open-source", "contributing"]
+keywords: ["git", "github", "cloning", "forking", "open-source", "contributing"]
+---
+
+One of the best ways to learn at **CodeHarborHub** is to look at how others build software. GitHub makes it incredibly easy to take an existing project and bring it onto your own computer. To do this, we use two main concepts: **Forking** and **Cloning**.
+
+## Forking vs. Cloning: The Big Difference
+
+These two terms are often confused, but they serve very different purposes in the professional developer's workflow.
+
+| Action | Where it happens | What it does | Use Case |
+| :--- | :--- | :--- | :--- |
+| **Forking** | On GitHub (Cloud) | Creates a **copy** of someone's repo under *your* account. | To contribute to Open Source or experiment with a project. |
+| **Cloning** | On your PC (Local) | Downloads a repo from GitHub to your hard drive. | To start coding on a project locally. |
+
+## 1. How to Fork a Repository
+
+Forking is the first step to contributing to an open-source project like **CodeHarborHub**.
+
+1.  Navigate to the repository you want to copy (e.g., `github.com/codeharborhub/mern-stack-app`).
+2.  In the top-right corner, click the **Fork** button.
+3.  GitHub will create a carbon copy of that project in your own profile (e.g., `github.com/your-username/mern-stack-app`).
+
+:::info Why Fork?
+You cannot "Push" code directly to a project you don't own. Forking gives you your own version where you have "Admin" rights to make any changes you want.
+:::
+
+## 2. How to Clone a Repository
+
+Once you have a repository on GitHub (either your own or a fork), you need to "Clone" it to your computer to actually edit the files.
+
+1.  On the GitHub repo page, click the green **`<>` Code** button.
+2.  Copy the **HTTPS** URL.
+3.  Open your terminal and run:
+
+```bash
+git clone https://github.com/your-username/your-repo-name.git
+```
+
+### What happens during a Clone?
+
+  * Git creates a new folder on your computer.
+  * It downloads every file and every folder.
+  * **Crucially:** It downloads the entire history (all previous commits).
+  * It automatically sets up the "Remote" (origin) so you can push/pull immediately.
+
+## The Open Source Contribution Flow
+
+This is the standard "Industrial Level" workflow for contributing to projects:
+
+```mermaid
+graph TD
+    A[Original Repo] -->|Fork| B[Your GitHub Fork]
+    B -->|Clone| C[Your Local PC]
+    C -->|Commit & Push| B
+    B -->|Pull Request| A
+```
+
+## Step 3: Keeping your Clone Updated
+
+If the original project (the one you forked) gets updated with new features, your local clone will become outdated. At **CodeHarborHub**, we use the `upstream` command to keep things synced.
+
+```bash
+# 1. Connect to the original 'Source' repo
+git remote add upstream https://github.com/codeharborhub/original-project.git
+
+# 2. Pull the latest changes from the original source
+git pull upstream main
+```
+
+## Common Scenarios
+
+| Problem | Solution |
+| :--- | :--- |
+| **"I just want to play with the code locally."** | Just **Clone** the repo. |
+| **"I want to fix a bug in CodeHarborHub."** | **Fork** it first, then **Clone** your fork. |
+| **"I deleted my local folder by mistake!"** | No problem! Just **Clone** it again from GitHub. |
+
+:::tip
+You can clone a repository directly into **VS Code**! Open VS Code, press `Ctrl+Shift+P`, type "Git: Clone," and paste the URL. It handles the terminal work for you!
+
+For example, if you want to clone the CodeHarborHub repository, you can use:
+
+```bash
+git clone [REPOSITORY_URL]
+```
+:::
@@ -0,0 +1,69 @@
+---
+title: "Creating Public & Private Repositories"
+sidebar_label: "7. Public vs. Private Repositories"
+sidebar_position: 7
+description: "Learn how to set up your project on GitHub and choose the right visibility for your code. This guide will walk you through the process of creating a new repository, understanding the differences between public and private repositories, and best practices for beginners. Whether you're sharing your work with the world or keeping it private, this tutorial will help you get started with GitHub repositories effectively."
+tags: ["git", "github", "repositories", "public vs private", "version control", "beginner guide"]
+keywords: ["git", "github", "repositories", "public vs private", "version control", "beginner guide"]
+---
+
+A **Repository** (or "Repo") is the digital container for your project. It holds all your code, documentation, and the complete history of every change you've ever made. At **CodeHarborHub**, we use GitHub to host these repositories so we can collaborate and showcase our work.
+
+## Public vs. Private: Which should you choose?
+
+When you create a repo, GitHub will ask you to choose its visibility. This is an important "Industrial Level" decision.
+
+| Feature | Public Repository | Private Repository |
+| :--- | :--- | :--- |
+| **Visibility** | Anyone on the internet can see your code. | Only you and people you invite can see it. |
+| **Collaboration** | Anyone can "Fork" and suggest changes. | Strictly controlled access. |
+| **Best For...** | Open Source, Portfolios, Community projects. | School assignments, Startup ideas, API Keys. |
+| **Cost** | Always Free. | Free (with limits for large teams). |
+
+## Step-by-Step: Creating a Repo on GitHub
+
+1.  **Login:** Go to [GitHub](https://github.com/) and click the **+** icon in the top right, then select **New repository**.
+2.  **Naming:** Choose a short, memorable name (e.g., `codeharborhub-web-automation`).
+3.  **Description:** Add a quick summary (this helps people find your project!).
+4.  **Choose Visibility:** Select **Public** or **Private**.
+
+## Initializing Options (The "Clean" Start)
+
+GitHub gives you three options to add to your repo immediately. We recommend checking these for most projects:
+
+* **Add a README file:** This is the "Front Door" of your project. It explains what the project does.
+* **Add .gitignore:** Choose a template (like Node or Python) to keep your repo clean.
+* **Choose a license:** For Public repos, a license (like MIT) tells people how they are allowed to use your code.
+
+## Connecting Your Local Code
+
+If you already have code on your computer and want to upload it to your new GitHub repo, follow the **Remote Connection** flow:
+
+```bash
+# 1. Add the link to GitHub (The "Remote")
+git remote add origin https://github.com/username/your-repo-name.git
+
+# 2. Rename your main branch (Standard practice)
+git branch -M main
+
+# 3. Push your code to the cloud
+git push -u origin main
+```
+
+## Use Case: When to go Private?
+
+At **CodeHarborHub**, we encourage "Learning in Public," but here is when you should definitely use a **Private** repository:
+
+1.  **The "Draft" Phase:** You have a messy project that isn't ready for your portfolio yet.
+2.  **Sensitive Data:** You are building an app for a local business (like the *Jila Sahakari Bank*) that contains internal logic.
+3.  **Assignments:** You are working on a coding challenge for a job interview.
+
+## Pro Tip: Changing Visibility Later
+
+Don't worry! Your choice isn't permanent. You can always start a project as **Private** while you're building the foundation and change it to **Public** when you are ready to launch it to the world.
+
+> **Settings $\rightarrow$ General $\rightarrow$ Danger Zone $\rightarrow$ Change visibility**
+
+:::info 
+Even if a repository is **Public**, no one can change your code without your permission. Others can only *suggest* changes via a **Pull Request**, which you must approve\!
+:::
@@ -0,0 +1,114 @@
+---
+title: "Staging Your Changes (git add)"
+sidebar_label: "2. git add"
+sidebar_position: 2
+description: "Learn how to use the git add command to prepare your files for a permanent snapshot. This guide will explain the concept of staging, how to select specific changes, and best practices for beginners. Whether you're working on a new feature or fixing a bug, understanding git add is essential for effective version control."
+tags: ["git", "git add", "staging", "version control", "beginner guide"]
+keywords: ["git", "git add", "staging", "version control", "beginner guide"]
+---
+
+In the **CodeHarborHub** workflow, we don't just "save" everything at once. We use a professional two-step process. The first step is **Staging**.
+
+The `git add` command tells Git: *"Hey, look at these specific changes. I want them to be part of my next save-point (commit)."*
+
+:::info
+Think of `git add` as the "Call to the Backdrop" in a photo shoot. You choose which people (files) you want to stand in front of the camera for the next photo (commit).
+:::
+
+## The "Photo Studio" Analogy
+
+Think of your project like a **Group Photo**:
+
+1.  **Working Directory (The Room):** Everyone is hanging out in the room. Some people are ready, some are still fixing their hair.
+2.  **Staging Area (The Backdrop):** You call specific people to stand in front of the camera. They are "Staged."
+3.  **Commit (The Photo):** You click the shutter button. Only the people standing at the backdrop are in the photo.
+
+## How to Use `git add`
+
+You can choose exactly which changes you want to prepare.
+
+<Tabs>
+<TabItem value="single" label="Single File" default>
+
+If you only want to stage one specific file:
+
+```bash
+git add index.html
+```
+
+</TabItem>
+<TabItem value="multiple" label="Multiple Files">
+
+If you want to stage a few specific files:
+
+```bash
+git add style.css script.js
+```
+
+</TabItem>
+<TabItem value="all" label="Everything (The Daily Favorite)">
+
+If you want to stage **every** change you've made in the entire folder:
+
+```bash
+git add .
+```
+
+*Note: The dot `.` represents the current directory.*
+
+</TabItem>
+</Tabs>
+
+:::note Important
+Using `git add .` is a common practice, but be cautious! It will stage **all** changes, including those you might not want to commit (like temporary files or sensitive information). Always double-check with `git status` before running this command.
+:::
+
+## The Logic Flow
+
+```mermaid
+graph LR
+    A[index.html &lpar;Modified&rpar;] -- "git add ." --> B[index.html &lpar;Staged&rpar;]
+    B -- "git commit" --> C[Stored in History]
+
+    subgraph "The Staging Area"
+    B
+    end
+```
+
+## Why not just save everything automatically?
+
+Beginners often ask: *"Why can't I just commit directly?"* At an **Industrial Level**, we use the Staging Area for **Precision**:
+
+  * **Scenario:** You worked on a new `Navbar` (finished) and a `Footer` (half-finished).
+  * **The Pro Way:** You only `git add Navbar.js` and commit it. Your half-finished footer stays safely in your "Working Directory" and doesn't break the main code\!
+
+## Verification: Did it work?
+
+After running `git add`, always check your progress with:
+
+```bash
+git status
+```
+
+**What you should see:**
+
+  * Files in **Red**: Changes that are NOT yet staged.
+  * Files in **Green**: Changes that ARE staged and ready to be committed.
+
+## Oops! How to Unstage?
+
+If you accidentally added a file to the staging area that you didn't mean to, don't panic\! You can "remove it from the backdrop" without deleting your code:
+
+```bash
+git reset index.html
+```
+
+This command unstages `index.html` but keeps your changes in the working directory. You can also unstage everything with:
+
+```bash
+git reset
+```
+
+:::info
+At **CodeHarborHub**, we recommend running `git status` before and after every `git add`. It helps you avoid accidentally staging sensitive files like `.env` or `node_modules`!
+:::