diff --git a/absolute-beginners/git-github-beginner/basic-git/branching-and-merging.mdx b/absolute-beginners/git-github-beginner/basic-git/branching-and-merging.mdx new file mode 100644 index 0000000..01af595 --- /dev/null +++ b/absolute-beginners/git-github-beginner/basic-git/branching-and-merging.mdx @@ -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: + + + + +```bash +# Create the branch +git branch feat-dark-mode + +# Switch to the branch +git checkout feat-dark-mode +``` + + + + +```bash +# Create and switch immediately +git checkout -b feat-dark-mode +``` + + + + +## 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." +::: \ No newline at end of file diff --git a/absolute-beginners/git-github-beginner/basic-git/cloning-and-forking.mdx b/absolute-beginners/git-github-beginner/basic-git/cloning-and-forking.mdx new file mode 100644 index 0000000..c4b72cb --- /dev/null +++ b/absolute-beginners/git-github-beginner/basic-git/cloning-and-forking.mdx @@ -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] +``` +::: \ No newline at end of file diff --git a/absolute-beginners/git-github-beginner/basic-git/creating-repositories.mdx b/absolute-beginners/git-github-beginner/basic-git/creating-repositories.mdx new file mode 100644 index 0000000..57be3f3 --- /dev/null +++ b/absolute-beginners/git-github-beginner/basic-git/creating-repositories.mdx @@ -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\! +::: \ No newline at end of file diff --git a/absolute-beginners/git-github-beginner/basic-git/git-add.mdx b/absolute-beginners/git-github-beginner/basic-git/git-add.mdx new file mode 100644 index 0000000..7df5880 --- /dev/null +++ b/absolute-beginners/git-github-beginner/basic-git/git-add.mdx @@ -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. + + + + +If you only want to stage one specific file: + +```bash +git add index.html +``` + + + + +If you want to stage a few specific files: + +```bash +git add style.css script.js +``` + + + + +If you want to stage **every** change you've made in the entire folder: + +```bash +git add . +``` + +*Note: The dot `.` represents the current directory.* + + + + +:::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 (Modified)] -- "git add ." --> B[index.html (Staged)] + 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`! +::: \ No newline at end of file diff --git a/absolute-beginners/git-github-beginner/basic-git/git-commit.mdx b/absolute-beginners/git-github-beginner/basic-git/git-commit.mdx new file mode 100644 index 0000000..8340c4a --- /dev/null +++ b/absolute-beginners/git-github-beginner/basic-git/git-commit.mdx @@ -0,0 +1,73 @@ +--- +title: "Committing Changes (git commit)" +sidebar_label: "3. git commit" +sidebar_position: 3 +description: "Learn how to create permanent save-points in your project history using the git commit command. This guide will explain the concept of commits, how to write effective commit messages, and best practices for beginners. Whether you're adding a new feature or fixing a bug, understanding git commit is essential for maintaining a clear and organized project history." +tags: ["git", "git commit", "committing changes", "version control", "beginner guide"] +keywords: ["git", "git commit", "committing changes", "version control", "beginner guide"] +--- + +In the **CodeHarborHub** workflow, a **Commit** is more than just a "save." It is a permanent snapshot of your project at a specific point in time. + +If `git add` is putting your files in a box, `git commit` is sealing that box, labeling it, and putting it on the shelf of history. + +:::info +Think of a commit as a "Save Point" in a video game. You can always go back to that point if you need to. It's a way to keep track of your progress and changes over time. +::: + +## The "Checkpoint" Concept + +Think of a video game. You don't want to restart the whole game every time you lose. You look for a **Checkpoint**. + +* **Working Directory:** You are playing the level (typing code). +* **Staging Area:** You reached the checkpoint flag (run `git add`). +* **Commit:** The game saves your progress (run `git commit`). + +## How to Use `git commit` + +To create a commit, you must always include a **Message** (`-m`). This message tells your future self (and your teammates) *what* you changed and *why*. + +```bash +git commit -m "feat: add user login validation logic" +``` + +### What happens behind the scenes? + +1. Git takes all the files you "Staged" (the green files in `git status`). +2. It creates a unique ID for this save-point (called a **SHA-1 Hash**). +3. It records your Name, Email, Date, and Message. + +## The Professional "Commit Rule" + +At an **Industrial Level**, we follow the **Conventional Commits** standard. This makes your project history easy to read. + +| Type | When to use? | Example Message | +| :--- | :--- | :--- | +| **feat** | A new feature for the user. | `feat: add dark mode toggle` | +| **fix** | Fixing a bug or error. | `fix: resolve crash on mobile header` | +| **docs** | Changes to documentation only. | `docs: update nginx installation guide` | +| **style** | Formatting, missing semi-colons, etc. | `style: fix indentation in index.html` | + +## Verification: Checking the History + +How do you see your "Shelf of History"? Use the log command: + +```bash +git log --oneline +``` + +**What you will see:** + +> `a1b2c3d feat: add user login validation logic` +> `e4f5g6h docs: initial project setup` + +## The "Golden Rules" of Committing + +1. **Commit Often:** Don't wait 5 hours to commit. Smaller commits are easier to fix if something goes wrong. +2. **One Feature, One Commit:** Don't fix a bug and add a new feature in the same commit. Keep them separate! +3. **Write Clear Messages:** Avoid messages like "Fixed stuff" or "Update." Be specific! + +:::info +Did you forget to add a file to your last commit? Instead of making a new one, you can "amend" the previous save: +`git commit --amend -m "updated message"` +::: \ No newline at end of file diff --git a/absolute-beginners/git-github-beginner/basic-git/git-reset.mdx b/absolute-beginners/git-github-beginner/basic-git/git-reset.mdx new file mode 100644 index 0000000..6ebb276 --- /dev/null +++ b/absolute-beginners/git-github-beginner/basic-git/git-reset.mdx @@ -0,0 +1,75 @@ +--- +title: "Undoing Changes (git reset)" +sidebar_label: "4. git reset" +sidebar_position: 4 +description: "Learn how to travel back in time and undo mistakes safely using the git reset command. This guide will explain the different modes of git reset, when to use each one, and best practices for beginners. Whether you need to fix a bad commit or unstage changes, understanding git reset is essential for maintaining a clean project history." +tags: ["git", "git reset", "undo changes", "version control", "beginner guide"] +keywords: ["git", "git reset", "undo changes", "version control", "beginner guide"] +--- + +Every developer makes mistakes. You might commit a bug, stage the wrong file, or realize your last three hours of work were a bad idea. At **CodeHarborHub**, we use `git reset` to move the project back to a "Known Good" state. + +## The Three Levels of "Undo" + +Think of `git reset` like a **Time Machine** with three different settings. Depending on how much you want to "erase," you choose a specific mode: + +### 1. Soft Reset (`--soft`) +**The "Keep my work" mode.** +This moves the history back one step, but keeps all your code changes in the **Staging Area**. Use this if you just want to rewrite your last commit message or add one more file to the save-point. + +```bash +git reset --soft HEAD~1 +``` + +### 2. Mixed Reset (Default) + +**The "Unstage my work" mode.** +This moves the history back, but takes your files out of the Staging Area and puts them back into your **Working Directory**. Your code is still there, but Git is no longer "ready to save" it. + +```bash +git reset HEAD~1 +``` + +### 3. Hard Reset (`--hard`) + +**The "Nuke it" mode.** +This destroys everything. It moves the history back and **deletes** all the code changes you made after that point. + +```bash +git reset --hard HEAD~1 +``` + +## Comparison Table + +| Mode | Changes History? | Keeps Code? | Where does code go? | +| :--- | :--- | :--- | :--- | +| **`--soft`** | Yes | Yes | Staging Area (Green) | +| **`--mixed`** | Yes | Yes | Working Directory (Red) | +| **`--hard`** | Yes | No | Deleted Forever | + +## Use Case: I committed a secret! + +Imagine you accidentally committed your `API_KEY` in a file called `.env`. You need to undo that commit immediately before pushing to GitHub. + +1. **Perform a Soft Reset:** + ```bash + git reset --soft HEAD~1 + ``` +2. **Unstage the secret file:** + ```bash + git rm --cached .env + ``` +3. **Commit again safely:** + ```bash + git commit -m "feat: add logic without secrets" + ``` + +## The Golden Rule of Reseting + +> **Never `git reset --hard` on a commit that you have already pushed to GitHub.** + +If you delete history locally that other team members have already downloaded, it will cause "Merge Conflicts" and headaches for the whole **CodeHarborHub** team. Only reset commits that are still only on your computer! + +:::danger Warning +`git reset --hard` is the only Git command that can actually **delete** your work. Use it with caution. If you aren't sure, always use `--soft` first! +::: \ No newline at end of file diff --git a/absolute-beginners/git-github-beginner/basic-git/gitignore.mdx b/absolute-beginners/git-github-beginner/basic-git/gitignore.mdx new file mode 100644 index 0000000..88b6cf5 --- /dev/null +++ b/absolute-beginners/git-github-beginner/basic-git/gitignore.mdx @@ -0,0 +1,93 @@ +--- +title: "Ignoring Files (.gitignore)" +sidebar_label: "5. .gitignore" +sidebar_position: 5 +description: "Learn how to prevent sensitive files and junk data from being tracked by Git. This guide will explain the purpose of the .gitignore file, how to create one, and best practices for beginners. Whether you're working on a personal project or collaborating with a team, understanding .gitignore is essential for maintaining a clean and secure codebase." +tags: ["git", ".gitignore", "ignoring files", "version control", "beginner guide"] +keywords: ["git", ".gitignore", "ignoring files", "version control", "beginner guide"] +--- + +In every project, there are files you **never** want to save in your history or upload to GitHub. These might be secret passwords, large "junk" folders, or temporary system files. + +At **CodeHarborHub**, we use a special file called `.gitignore` to tell Git: "Ignore these files. Pretend they don't exist." + +## Why do we need it? + +If you don't use a `.gitignore`, your repository will quickly become bloated and dangerous: + +1. **Security:** You might accidentally push your `DATABASE_PASSWORD` or `API_KEY` to the public. +2. **Performance:** Folders like `node_modules` can contain thousands of files. Uploading them makes your `git push` slow and heavy. +3. **Cleanliness:** System files like `.DS_Store` (Mac) or `Thumbs.db` (Windows) add "noise" to your project that other developers don't need. + +## How to Create One + +1. In your project's **root folder**, create a new file. +2. Name it exactly `.gitignore` (The dot at the beginning is mandatory). +3. Inside the file, type the names of the files or folders you want to ignore. + +### Example `.gitignore` for a MERN Stack Project: + +```text +# Dependency folders (very heavy) +node_modules/ + +# Environment variables (contains secrets!) +.env +*.local + +# Build output (generated files) +dist/ +build/ + +# System files +.DS_Store +Thumbs.db +``` + +## How it Works + +When you run `git add .`, Git checks your `.gitignore` file first. If a file matches a pattern in that list, Git simply skips it. + +```mermaid +graph TD + A[Modified Files] --> B{In .gitignore?} + B -- Yes --> C[Ignore File] + B -- No --> D[Add to Staging Area] + D --> E[Commit to History] +``` + +## Professional Use Cases + +| Pattern | What it ignores | Use Case | +| :--- | :--- | :--- | +| `*.log` | All files ending in `.log`. | Hiding error logs. | +| `config/secrets.json` | A specific file path. | Protecting specific API keys. | +| `temp/` | The entire 'temp' folder. | Ignoring temporary cache. | +| `!important.log` | **Exceptions:** Ignore logs *except* this one. | Keeping one specific log file. | + +## The "Already Tracked" Trap + +:::danger Warning +If you have **already committed** a file and then add it to `.gitignore`, Git will **continue to track it.** +::: + +To fix this and tell Git to "stop watching" a file that was already committed: + +```bash +# Remove from Git index, but keep the file on your computer +git rm --cached +``` + +## Pro Tip: Global Gitignore + +Tired of adding `.DS_Store` to every single project? You can create a **Global Gitignore** that applies to every repository on your computer: + +```bash +git config --global core.excludesfile ~/.gitignore_global +``` + +:::info +Then, create the `~/.gitignore_global` file and add your common patterns there. This way, you only have to write them once! + +Don't write your `.gitignore` from scratch! Use [gitignore.io](https://www.toptal.com/developers/gitignore). Just type "Node", "React", and "Windows," and it will generate a professional file for you instantly. +::: \ No newline at end of file diff --git a/absolute-beginners/git-github-beginner/basic-git/remote-and-pushing.mdx b/absolute-beginners/git-github-beginner/basic-git/remote-and-pushing.mdx new file mode 100644 index 0000000..6d4f2c9 --- /dev/null +++ b/absolute-beginners/git-github-beginner/basic-git/remote-and-pushing.mdx @@ -0,0 +1,94 @@ +--- +title: "Adding Remotes & Pushing Changes" +sidebar_label: "8. Remotes & Pushing" +sidebar_position: 8 +description: "Learn how to connect your local Git repository to GitHub and upload your code to the cloud. This guide will explain how to add a remote repository, push your commits to GitHub, and troubleshoot common issues. Whether you're sharing your work with the world or collaborating with others, understanding remotes and pushing is essential for effective version control." +tags: ["git", "remotes", "pushing", "version control", "beginner guide"] +keywords: ["git", "remotes", "pushing", "version control", "beginner guide"] +--- + +Until now, all your "Save Points" (Commits) have lived only on your laptop. If your computer crashes, your code is gone! To prevent this and to share our work with the **CodeHarborHub** community, we use **Remotes**. + +A **Remote** is simply a version of your project that is hosted on the internet (usually on GitHub). + +## Step 1: Adding a Remote + +Think of this like "Pairing" your phone to a Bluetooth speaker. You are telling your local Git folder exactly where its "Cloud Home" is located. + +1. **Create a Repo** on GitHub (without initializing it with a README). +2. **Copy the URL** (e.g., `https://github.com/user/repo.git`). +3. **Run the command:** + +```bash +git remote add origin https://github.com/your-username/your-repo-name.git +``` + +### What does "origin" mean? + +In the developer world, `origin` is the standard nickname for your main GitHub repository. You could name it "cloud" or "github," but stick with `origin` to follow the industrial standard. + +## Step 2: Pushing Your Changes + +"Pushing" is the process of uploading your local commits to the remote server. + +```bash +# Push your 'main' branch to the 'origin' remote +git push -u origin main +``` + +### What does the `-u` flag do? + +The `-u` (upstream) flag "remembers" your preferences. After running this once, you can just type `git push` in the future, and Git will know exactly where to send the code. + +## The Local-to-Cloud Workflow + +```mermaid +graph LR + A[Working Directory] -->|git add| B[Staging Area] + B -->|git commit| C[Local Repository] + C -->|git push| D[GitHub ( Cloud )] + + subgraph "Your Computer" + A + B + C + end + + subgraph "The Internet" + D + end +``` + +## Common Push Scenarios + +| Command | Use Case | +| :--- | :--- | +| **`git remote -v`** | Check which GitHub URL your project is currently linked to. | +| **`git push origin feature-name`** | Push a specific branch instead of the main one. | +| **`git push --force`** | **Dangerous:** Overwrites the cloud history. Avoid this at CodeHarborHub! | + +## Troubleshooting: "Rejected" Pushes + +Sometimes, GitHub will reject your push with an error. This usually happens because **someone else** pushed code while you were working. + +**The Fix:** You must "Pull" their changes first, merge them, and then push again. + +```bash +# 1. Get the latest code from GitHub +git pull origin main + +# 2. Now you can safely push +git push origin main +``` + +## Industrial Level Best Practice + +At **CodeHarborHub**, we never "Push to Main" directly when working in a team. + +1. Create a **Branch** (`git checkout -b feature-xyz`). +2. Push the **Branch** (`git push origin feature-xyz`). +3. Open a **Pull Request** on GitHub for a code review. This way, we maintain a clean and stable `main` branch while still collaborating effectively. + +:::info +You can have multiple remotes! For example, you could have one remote named `origin` for GitHub and another named `heroku` to automatically deploy your app to a live server. +::: \ No newline at end of file