Skip to content

Commit 9495885

Browse files
ajay-dhangarajay-dhangar
authored
Merge pull request #237 from codeharborhub/dev-1
added docs for github actions doc
2 parents 3c65e11 + b84de89 commit 9495885

File tree

8 files changed

+715
-0
lines changed

8 files changed

+715
-0
lines changed

‎absolute-beginners/git-github-beginner/basic-git/branching-and-merging.mdx‎

Lines changed: 105 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
---
2+
title: "Branching and Merging"
3+
sidebar_label: "6. Branching & Merging"
4+
sidebar_position: 6
5+
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."
6+
tags: ["git", "branching", "merging", "version control", "beginner guide"]
7+
keywords: ["git", "branching", "merging", "version control", "beginner guide"]
8+
---
9+
10+
In a professional environment like **CodeHarborHub**, we never work directly on the "Live" code (the `main` branch). Instead, we use **Branches**.
11+
12+
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.
13+
14+
## The Branching Workflow
15+
16+
Imagine you are building a website. The `main` branch is the version users see. You want to add a "Dark Mode."
17+
18+
1. **Create a Branch:** You step into a parallel universe called `feat-dark-mode`.
19+
2. **Work:** You write your CSS and JS. The `main` branch remains untouched and stable.
20+
3. **Merge:** Once the dark mode is perfect, you bring those changes back into the `main` universe.
21+
22+
## Step 1: Creating and Switching
23+
24+
You can create a branch and move into it using these commands:
25+
26+
<Tabs>
27+
<TabItem value="standard" label="The 2-Step Way" default>
28+
29+
```bash
30+
# Create the branch
31+
git branch feat-dark-mode
32+
33+
# Switch to the branch
34+
git checkout feat-dark-mode
35+
```
36+
37+
</TabItem>
38+
<TabItem value="pro" label="The Pro Way (1-Step)">
39+
40+
```bash
41+
# Create and switch immediately
42+
git checkout -b feat-dark-mode
43+
```
44+
45+
</TabItem>
46+
</Tabs>
47+
48+
## Step 2: Merging Changes
49+
50+
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:
51+
52+
**1. Switch back to the destination (Main):**
53+
54+
```bash
55+
git checkout main
56+
```
57+
58+
**2. Pull the changes in:**
59+
60+
```bash
61+
git merge feat-dark-mode
62+
```
63+
64+
**3. Cleanup (Optional):**
65+
Since the feature is now part of `main`, you can delete the temporary branch:
66+
67+
```bash
68+
git branch -d feat-dark-mode
69+
```
70+
71+
## The Logic of Merging
72+
73+
```mermaid
74+
graph LR
75+
A[Commit 1: Main] --> B[Commit 2: Main]
76+
B --> C[Branch: feat-dark-mode]
77+
C --> D[Commit 3: Dark Mode CSS]
78+
B --> E[Commit 4: Main Hotfix]
79+
D --> F{Merge}
80+
E --> F
81+
F --> G[Commit 5: Final Project]
82+
```
83+
84+
## Handling Merge Conflicts
85+
86+
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**.
87+
88+
**How to fix it:**
89+
90+
1. Open the file in **VS Code**.
91+
2. You will see markers: `<<<<<<< HEAD` (Your version) and `>>>>>>> branch-name` (Their version).
92+
3. Delete the version you don't want and remove the markers.
93+
4. `git add` the file and `git commit` to finish the merge.
94+
95+
## Industrial Best Practices
96+
97+
| Rule | Why? |
98+
| :--- | :--- |
99+
| **Descriptive Names** | Use `feat/login-ui` or `fix/header-logo` so others know what the branch is for. |
100+
| **Keep Branches Small** | Don't build five features in one branch. One branch = One task. |
101+
| **Pull Before Merge** | Always run `git pull origin main` before merging to ensure you have the latest team updates. |
102+
103+
:::info
104+
Not sure what branch you are on? Run `git branch`. The one with the asterisk (`*`) and highlighted in green is your current "Parallel Universe."
105+
:::

‎absolute-beginners/git-github-beginner/basic-git/cloning-and-forking.mdx‎

Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
---
2+
title: "Cloning and Forking"
3+
sidebar_label: "9. Cloning & Forking"
4+
sidebar_position: 9
5+
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."
6+
tags: ["git", "github", "cloning", "forking", "open-source", "contributing"]
7+
keywords: ["git", "github", "cloning", "forking", "open-source", "contributing"]
8+
---
9+
10+
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**.
11+
12+
## Forking vs. Cloning: The Big Difference
13+
14+
These two terms are often confused, but they serve very different purposes in the professional developer's workflow.
15+
16+
| Action | Where it happens | What it does | Use Case |
17+
| :--- | :--- | :--- | :--- |
18+
| **Forking** | On GitHub (Cloud) | Creates a **copy** of someone's repo under *your* account. | To contribute to Open Source or experiment with a project. |
19+
| **Cloning** | On your PC (Local) | Downloads a repo from GitHub to your hard drive. | To start coding on a project locally. |
20+
21+
## 1. How to Fork a Repository
22+
23+
Forking is the first step to contributing to an open-source project like **CodeHarborHub**.
24+
25+
1. Navigate to the repository you want to copy (e.g., `github.com/codeharborhub/mern-stack-app`).
26+
2. In the top-right corner, click the **Fork** button.
27+
3. GitHub will create a carbon copy of that project in your own profile (e.g., `github.com/your-username/mern-stack-app`).
28+
29+
:::info Why Fork?
30+
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.
31+
:::
32+
33+
## 2. How to Clone a Repository
34+
35+
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.
36+
37+
1. On the GitHub repo page, click the green **`<>` Code** button.
38+
2. Copy the **HTTPS** URL.
39+
3. Open your terminal and run:
40+
41+
```bash
42+
git clone https://github.com/your-username/your-repo-name.git
43+
```
44+
45+
### What happens during a Clone?
46+
47+
* Git creates a new folder on your computer.
48+
* It downloads every file and every folder.
49+
* **Crucially:** It downloads the entire history (all previous commits).
50+
* It automatically sets up the "Remote" (origin) so you can push/pull immediately.
51+
52+
## The Open Source Contribution Flow
53+
54+
This is the standard "Industrial Level" workflow for contributing to projects:
55+
56+
```mermaid
57+
graph TD
58+
A[Original Repo] -->|Fork| B[Your GitHub Fork]
59+
B -->|Clone| C[Your Local PC]
60+
C -->|Commit & Push| B
61+
B -->|Pull Request| A
62+
```
63+
64+
## Step 3: Keeping your Clone Updated
65+
66+
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.
67+
68+
```bash
69+
# 1. Connect to the original 'Source' repo
70+
git remote add upstream https://github.com/codeharborhub/original-project.git
71+
72+
# 2. Pull the latest changes from the original source
73+
git pull upstream main
74+
```
75+
76+
## Common Scenarios
77+
78+
| Problem | Solution |
79+
| :--- | :--- |
80+
| **"I just want to play with the code locally."** | Just **Clone** the repo. |
81+
| **"I want to fix a bug in CodeHarborHub."** | **Fork** it first, then **Clone** your fork. |
82+
| **"I deleted my local folder by mistake!"** | No problem! Just **Clone** it again from GitHub. |
83+
84+
:::tip
85+
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!
86+
87+
For example, if you want to clone the CodeHarborHub repository, you can use:
88+
89+
```bash
90+
git clone [REPOSITORY_URL]
91+
```
92+
:::

‎absolute-beginners/git-github-beginner/basic-git/creating-repositories.mdx‎

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
---
2+
title: "Creating Public & Private Repositories"
3+
sidebar_label: "7. Public vs. Private Repositories"
4+
sidebar_position: 7
5+
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."
6+
tags: ["git", "github", "repositories", "public vs private", "version control", "beginner guide"]
7+
keywords: ["git", "github", "repositories", "public vs private", "version control", "beginner guide"]
8+
---
9+
10+
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.
11+
12+
## Public vs. Private: Which should you choose?
13+
14+
When you create a repo, GitHub will ask you to choose its visibility. This is an important "Industrial Level" decision.
15+
16+
| Feature | Public Repository | Private Repository |
17+
| :--- | :--- | :--- |
18+
| **Visibility** | Anyone on the internet can see your code. | Only you and people you invite can see it. |
19+
| **Collaboration** | Anyone can "Fork" and suggest changes. | Strictly controlled access. |
20+
| **Best For...** | Open Source, Portfolios, Community projects. | School assignments, Startup ideas, API Keys. |
21+
| **Cost** | Always Free. | Free (with limits for large teams). |
22+
23+
## Step-by-Step: Creating a Repo on GitHub
24+
25+
1. **Login:** Go to [GitHub](https://github.com/) and click the **+** icon in the top right, then select **New repository**.
26+
2. **Naming:** Choose a short, memorable name (e.g., `codeharborhub-web-automation`).
27+
3. **Description:** Add a quick summary (this helps people find your project!).
28+
4. **Choose Visibility:** Select **Public** or **Private**.
29+
30+
## Initializing Options (The "Clean" Start)
31+
32+
GitHub gives you three options to add to your repo immediately. We recommend checking these for most projects:
33+
34+
* **Add a README file:** This is the "Front Door" of your project. It explains what the project does.
35+
* **Add .gitignore:** Choose a template (like Node or Python) to keep your repo clean.
36+
* **Choose a license:** For Public repos, a license (like MIT) tells people how they are allowed to use your code.
37+
38+
## Connecting Your Local Code
39+
40+
If you already have code on your computer and want to upload it to your new GitHub repo, follow the **Remote Connection** flow:
41+
42+
```bash
43+
# 1. Add the link to GitHub (The "Remote")
44+
git remote add origin https://github.com/username/your-repo-name.git
45+
46+
# 2. Rename your main branch (Standard practice)
47+
git branch -M main
48+
49+
# 3. Push your code to the cloud
50+
git push -u origin main
51+
```
52+
53+
## Use Case: When to go Private?
54+
55+
At **CodeHarborHub**, we encourage "Learning in Public," but here is when you should definitely use a **Private** repository:
56+
57+
1. **The "Draft" Phase:** You have a messy project that isn't ready for your portfolio yet.
58+
2. **Sensitive Data:** You are building an app for a local business (like the *Jila Sahakari Bank*) that contains internal logic.
59+
3. **Assignments:** You are working on a coding challenge for a job interview.
60+
61+
## Pro Tip: Changing Visibility Later
62+
63+
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.
64+
65+
> **Settings $\rightarrow$ General $\rightarrow$ Danger Zone $\rightarrow$ Change visibility**
66+
67+
:::info
68+
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\!
69+
:::

‎absolute-beginners/git-github-beginner/basic-git/git-add.mdx‎

Lines changed: 114 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,114 @@
1+
---
2+
title: "Staging Your Changes (git add)"
3+
sidebar_label: "2. git add"
4+
sidebar_position: 2
5+
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."
6+
tags: ["git", "git add", "staging", "version control", "beginner guide"]
7+
keywords: ["git", "git add", "staging", "version control", "beginner guide"]
8+
---
9+
10+
In the **CodeHarborHub** workflow, we don't just "save" everything at once. We use a professional two-step process. The first step is **Staging**.
11+
12+
The `git add` command tells Git: *"Hey, look at these specific changes. I want them to be part of my next save-point (commit)."*
13+
14+
:::info
15+
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).
16+
:::
17+
18+
## The "Photo Studio" Analogy
19+
20+
Think of your project like a **Group Photo**:
21+
22+
1. **Working Directory (The Room):** Everyone is hanging out in the room. Some people are ready, some are still fixing their hair.
23+
2. **Staging Area (The Backdrop):** You call specific people to stand in front of the camera. They are "Staged."
24+
3. **Commit (The Photo):** You click the shutter button. Only the people standing at the backdrop are in the photo.
25+
26+
## How to Use `git add`
27+
28+
You can choose exactly which changes you want to prepare.
29+
30+
<Tabs>
31+
<TabItem value="single" label="Single File" default>
32+
33+
If you only want to stage one specific file:
34+
35+
```bash
36+
git add index.html
37+
```
38+
39+
</TabItem>
40+
<TabItem value="multiple" label="Multiple Files">
41+
42+
If you want to stage a few specific files:
43+
44+
```bash
45+
git add style.css script.js
46+
```
47+
48+
</TabItem>
49+
<TabItem value="all" label="Everything (The Daily Favorite)">
50+
51+
If you want to stage **every** change you've made in the entire folder:
52+
53+
```bash
54+
git add .
55+
```
56+
57+
*Note: The dot `.` represents the current directory.*
58+
59+
</TabItem>
60+
</Tabs>
61+
62+
:::note Important
63+
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.
64+
:::
65+
66+
## The Logic Flow
67+
68+
```mermaid
69+
graph LR
70+
A[index.html &lpar;Modified&rpar;] -- "git add ." --> B[index.html &lpar;Staged&rpar;]
71+
B -- "git commit" --> C[Stored in History]
72+
73+
subgraph "The Staging Area"
74+
B
75+
end
76+
```
77+
78+
## Why not just save everything automatically?
79+
80+
Beginners often ask: *"Why can't I just commit directly?"* At an **Industrial Level**, we use the Staging Area for **Precision**:
81+
82+
* **Scenario:** You worked on a new `Navbar` (finished) and a `Footer` (half-finished).
83+
* **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\!
84+
85+
## Verification: Did it work?
86+
87+
After running `git add`, always check your progress with:
88+
89+
```bash
90+
git status
91+
```
92+
93+
**What you should see:**
94+
95+
* Files in **Red**: Changes that are NOT yet staged.
96+
* Files in **Green**: Changes that ARE staged and ready to be committed.
97+
98+
## Oops! How to Unstage?
99+
100+
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:
101+
102+
```bash
103+
git reset index.html
104+
```
105+
106+
This command unstages `index.html` but keeps your changes in the working directory. You can also unstage everything with:
107+
108+
```bash
109+
git reset
110+
```
111+
112+
:::info
113+
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`!
114+
:::

0 commit comments

Comments
 (0)