diff --git a/absolute-beginners/backend-beginner/version-control-systems/_category_.json b/absolute-beginners/backend-beginner/version-control-systems/_category_.json new file mode 100644 index 0000000..0b4a126 --- /dev/null +++ b/absolute-beginners/backend-beginner/version-control-systems/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "Version Control Systems", + "position": 3, + "link": { + "type": "generated-index", + "description": "Learn how to manage your code history, collaborate with others, and never lose a line of code again. This is the most essential skill for any modern developer." + } +} \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/version-control-systems/git-setup-guide.mdx b/absolute-beginners/backend-beginner/version-control-systems/git-setup-guide.mdx new file mode 100644 index 0000000..6116de9 --- /dev/null +++ b/absolute-beginners/backend-beginner/version-control-systems/git-setup-guide.mdx @@ -0,0 +1,133 @@ +--- +sidebar_position: 6 +title: "Git Setup & Your First Repo" +sidebar_label: "6. Setup Guide" +description: "Step-by-step instructions to install Git, configure your profile, and push your first project to GitHub." +--- + +It’s time to stop reading and start doing! In this guide, we will transform your computer into a developer workstation. + +## Step 1: Install Git + +First, we need to get the Git engine running on your machine. + + + + + 1. Download the **[Git for Windows](https://git-scm.com/download/win)** installer. + 2. Run the `.exe` file. + 3. **Important:** When asked about the "Default Editor," you can choose **Visual Studio Code**. + 4. Keep all other settings as "Default" and click **Install**. + + + + + 1. Open your Terminal (Command + Space, type `Terminal`). + 2. Type `git --version` and hit Enter. + 3. If you don't have it, a popup will ask you to install **Xcode Command Line Tools**. Click **Install**. + 4. Alternatively, if you use [Homebrew](https://brew.sh/), run: `brew install git`. + + + + + Open your terminal and run the command for your distribution: + * **Ubuntu/Debian:** `sudo apt install git-all` + * **Fedora:** `sudo dnf install git-all` + + + + +## Step 2: Configure Your Identity + +Git needs to know who is making changes. Open your terminal (or **Git Bash** on Windows) and type these two lines: + +```bash +git config --global user.name "Your Name" +git config --global user.email "your-email@example.com" +``` + +*Note: Use the same email address you plan to use for your GitHub account.* + +## Step 3: Create Your First Repository + +Let's create a "Hello World" project and track it with Git. + +### 1. Create a Folder + +```bash +mkdir my-first-repo +cd my-first-repo +``` + +### 2. Initialize Git + +This creates a hidden `.git` folder. This is where the "Time Machine" lives! + +```bash +git init +``` + +### 3. Create a File + +Create a simple file named `hello.txt` and add some text to it. + +### 4. The Magic Sequence (Add & Commit) + +```bash +# Add the file to the Staging Area +git add hello.txt + +# Save the snapshot to the Local Repository +git commit -m "feat: my very first commit" +``` + +## Step 4: Connect to GitHub + +Now, let's put your code in the cloud so the world can see it. + +1. Go to **[GitHub.com](https://github.com)** and create a free account. +2. Click the **+** icon in the top right and select **New Repository**. +3. Name it `my-first-repo` and click **Create repository**. +4. GitHub will give you a "Remote URL" (it looks like `https://github.com/your-username/my-first-repo.git`). + +**Run these commands in your terminal to link your computer to GitHub:** + +```bash +# Link your local repo to the cloud +git remote add origin https://github.com/your-username/my-first-repo.git + +# Rename your main branch to 'main' (standard practice) +git branch -M main + +# Upload your code! +git push -u origin main +``` + +## How to Check Your Work + +Refresh your GitHub repository page. You should see your `hello.txt` file sitting there! + +```mermaid +sequenceDiagram + participant PC as Your Computer (Local) + participant GH as GitHub (Cloud) + + PC->>PC: git init + PC->>PC: git add & commit + PC->>GH: git push + GH-->>PC: Successfully uploaded! + +``` + +## Common Commands Cheat Sheet + +| Command | Purpose | +| --- | --- | +| `git status` | See which files are modified or staged. | +| `git log` | See the history of all your commits. | +| `git diff` | See exactly what lines changed in your files. | +| `git branch` | List your current branches. | + +:::success 🎉 Congratulations! +You are now officially using Version Control. You have a local history on your computer and a backup in the cloud. You are ready to start building real backend applications! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/version-control-systems/git.mdx b/absolute-beginners/backend-beginner/version-control-systems/git.mdx new file mode 100644 index 0000000..84f807c --- /dev/null +++ b/absolute-beginners/backend-beginner/version-control-systems/git.mdx @@ -0,0 +1,101 @@ +--- +sidebar_position: 2 +title: "Git - The Industry Standard" +sidebar_label: "2. Git" +description: "Master the world's most popular Distributed Version Control System." +--- + +**Git** is a distributed version control system. This means that every developer’s computer contains the **entire history** of the project. It is fast, efficient, and used by millions of companies including Google, Microsoft, and Netflix. + +## The Git Workflow + +Before typing commands, you must understand the **Three Stages** of Git. Think of it like taking a professional photo: + +1. **Working Directory:** You are posing for the photo (Writing code). +2. **Staging Area:** You are "frozen" in the frame, but the shutter hasn't clicked (Preparing code). +3. **Local Repository:** The photo is saved to the memory card (Saved forever). + +```mermaid +graph LR + A[Working Directory] -->|git add| B[Staging Area] + B -->|git commit| C[Local Repository] + C -->|git push| D[Remote/GitHub] +``` + +## Essential Git Commands + +How do you actually use it? You can choose between using the **Terminal** (for power users) or a **GUI** (for a visual experience). + + + + +```bash +# 1. Start a new repository +git init + +# 2. Check what has changed +git status + +# 3. Add a specific file to the 'Staging Area' +git add index.js + +# 4. Save the snapshot with a message +git commit -m "feat: add user login logic" + +# 5. Send your code to GitHub +git push origin main + +``` + + + + +1. **VS Code:** Click the "Source Control" icon on the left sidebar. +2. **Staging:** Click the **+** icon next to the file name. +3. **Commit:** Type your message in the box and click **Commit**. +4. **Sync:** Click **Sync Changes** to push to the cloud. + + + + +## Branching: Parallel Realities + +The most powerful feature of Git is **Branching**. + +Imagine you want to add a "Dark Mode" to your app, but you don't want to risk breaking the current working version. You create a branch. + +```mermaid +gitGraph + commit id: "Initial" + commit id: "Setup API" + branch feature-dark-mode + checkout feature-dark-mode + commit id: "Add CSS" + commit id: "Add Toggle" + checkout main + merge feature-dark-mode + commit id: "Launch v1.1" + +``` + +## Why CodeHarborHub Recommends Git + +* **Offline Capability:** You can save your progress while traveling or if your internet is down. +* **Safety:** Every "Commit" is a checksum (a unique ID). It is almost impossible to lose data or corrupt the history. +* **The Ecosystem:** Since Git is the standard, it integrates with every major tool like **VS Code**, **Docker**, and **Vercel**. + +## Recommended Resources + +* **[Oh My Git!](https://ohmygit.org/)**: An open-source game to learn Git visually. +* **[Git Cheat Sheet by GitHub](https://education.github.com/git-cheat-sheet-education.pdf)**: A handy PDF to keep on your desk. + +## Summary Checklist + +* [x] I understand the 3 stages: Working Directory, Staging, and Repository. +* [x] I can initialize a project with `git init`. +* [x] I know that `git add` prepares my changes and `git commit` saves them. +* [x] I understand that branches allow for safe experimentation. + +:::tip Pro-Tip +Always write **clear commit messages**. Instead of writing "Fixed stuff," write "fix: resolve login button alignment on mobile." Your future self (and your team) will thank you! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/version-control-systems/intro-to-vcs.mdx b/absolute-beginners/backend-beginner/version-control-systems/intro-to-vcs.mdx new file mode 100644 index 0000000..54ea2a9 --- /dev/null +++ b/absolute-beginners/backend-beginner/version-control-systems/intro-to-vcs.mdx @@ -0,0 +1,67 @@ +--- +sidebar_position: 1 +title: "Introduction to Version Control" +sidebar_label: "1. What is VCS?" +description: "Understand the concept of Version Control Systems and why they are the Time Machine of software development." +--- + +Imagine you are working on a massive backend project. You’ve spent 10 hours writing the perfect API. Suddenly, you make a small change, and the entire server crashes. You try to undo it, but you've already saved the file. You can't remember what the code looked like before. + +**This is where Version Control Systems (VCS) save your life.** + +## 🧐 What is Version Control? + +A **Version Control System** is a software tool that tracks every single change you make to your code. It’s like a "Save Game" feature in a video game. If you run into a boss (a bug) that you can't beat, you can simply reload your previous save point. + +### The "Time Machine" Analogy +Without VCS, your folder looks like this: +* `server.js` +* `server_final.js` +* `server_final_v2.js` +* `server_DO_NOT_DELETE.js` + +With VCS, you have **one** file named `server.js`, but you can travel back in time to see exactly what that file looked like 5 minutes, 5 days, or 5 months ago. + +## Why is it Essential? + +### 1. Collaboration (The "No-Clash" Rule) +In a professional setting, five developers might be editing the same file at the same time. A VCS intelligently **merges** their changes together so no one's work is overwritten. + +### 2. Traceability (The "Who Did This?" Rule) +VCS keeps a log of **Who** changed **What** and **Why**. This isn't for blaming people; it's for understanding the logic behind a change months after it happened. + +### 3. Branching (The "Parallel Universe" Rule) +You can create a **Branch** to test a crazy new idea. If the idea fails, you just delete the branch, and your main code remains perfectly safe. If it works, you merge it back into the main project. + +## Two Types of VCS + +There are two main ways these systems are built: + +### A. Centralized VCS (CVCS) +There is one single central server that stores all the versions. Developers "check out" files from that server. +* **Example:** SVN (Subversion). +* **Cons:** If the server goes down, no one can save their work. + +### B. Distributed VCS (DVCS) +Every developer has a **full copy** of the entire project history on their own computer. +* **Example:** Git, Mercurial. +* **Pros:** You can work offline, and if the main server dies, any developer's computer can be used to restore it. + +## Current Market Favorites + +Currently, the world of programming is dominated by these three: + +1. **Git:** The undisputed king (Distributed). +2. **SVN:** Still used in some older, large corporate environments (Centralized). +3. **Mercurial:** A friendly alternative to Git (Distributed). + +## Summary Checklist + +* [x] I understand that VCS is a history tracker for my code. +* [x] I know that "Branching" allows me to experiment safely. +* [x] I understand that most modern systems are "Distributed." +* [x] I am ready to learn the most popular tool in the world: **Git**. + +:::tip Fun Fact +The most popular VCS today, **Git**, was created by **Linus Torvalds** in just 10 days because he was unhappy with the other tools available for building the Linux kernel! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/version-control-systems/mercurial.mdx b/absolute-beginners/backend-beginner/version-control-systems/mercurial.mdx new file mode 100644 index 0000000..dff5c54 --- /dev/null +++ b/absolute-beginners/backend-beginner/version-control-systems/mercurial.mdx @@ -0,0 +1,96 @@ +--- +sidebar_position: 4 +title: "Mercurial - The Streamlined Alternative" +sidebar_label: "4. Mercurial" +description: "Learn about Mercurial, a distributed version control system focused on simplicity and performance." +--- + +**Mercurial** (often shortened to **hg**, the chemical symbol for Mercury) is a **Distributed Version Control System (DVCS)**. It was released at almost the exact same time as Git. While Git focused on being powerful and flexible, Mercurial focused on being **predictable, efficient, and easy to use.** + +## Why Choose Mercurial? + +Many major tech companies (like **Meta/Facebook** in their early years) chose Mercurial over Git for several reasons: + +1. **Consistent Commands:** In Git, a single command might do five different things depending on the "flags" you use. In Mercurial, each command has one clear purpose. +2. **Safety First:** Mercurial makes it very difficult to "rewrite history." While Git allows you to delete or change old saves (which can be dangerous), Mercurial treats history as a permanent record. +3. **Scalability:** Mercurial is world-class at handling repositories with millions of files and thousands of developers. +4. **The "Extension" Model:** The core of Mercurial is very simple. If you want advanced features (like branching or special logs), you turn on "extensions" only when you need them. + +## The Mercurial Workflow + +Mercurial uses a "Commit-to-Local" workflow similar to Git, but it skips the "Staging Area." You go directly from your files to a save point. + +```mermaid +graph LR + A[Working Directory] -->|hg commit| B[Local Repository] + B -->|hg push| C[Remote Repository] + C -->|hg pull| B + B -->|hg update| A + +``` + +## Essential Mercurial Commands + +If you know Git, these will look very familiar, but notice how the "Staging" step is missing: + + + + +```bash +# 1. Create a new repository +hg init + +# 2. Add files to be tracked (only need to do this once) +hg add + +# 3. Save your changes directly +hg commit -m "feat: added basic routing logic" + +# 4. Pull changes from the server +hg pull + +# 5. Update your local files with what you just pulled +hg update + +# 6. Send your changes to the server +hg push + +``` + + + + +Just like SVN has TortoiseSVN, Mercurial has **TortoiseHg**: + +1. **Workbench:** A powerful visual tool to see your "Changelog" (history tree). +2. **Commit Tool:** A side-by-side view where you can see exactly which lines of code changed before you save. +3. **Sync:** Dedicated buttons for Pull, Update, and Push. + + + + +## Mercurial vs. Git + +| Feature | Mercurial (hg) | Git | +| --- | --- | --- | +| **Staging Area** | No (Direct Commits) | Yes (`git add`) | +| **Command Logic** | Intuitive and consistent | Powerful but complex | +| **History** | Usually permanent (Safe) | Can be modified (Flexible) | +| **Performance** | Excellent for huge repos | Fast, but can lag on massive monorepos | + +## Recommended Resources + +* **[Mercurial: The Definitive Guide](http://hgbook.red-bean.com/)**: A comprehensive online book for learning Mercurial from scratch. +* **[Hg Init](http://hginit.com/)**: A famous tutorial by Joel Spolsky (founder of Stack Overflow) designed specifically for people moving from SVN to Mercurial. +* **[Official Mercurial Wiki](https://www.mercurial-scm.org/wiki/)**: The go-to spot for technical documentation and extension lists. + +## Summary Checklist + +* [x] I understand that Mercurial is a "Distributed" system like Git. +* [x] I know that Mercurial (hg) uses a simpler workflow without a staging area. +* [x] I recognize that Mercurial is built for safety and scalability. +* [x] I have seen the `hg commit` and `hg push` commands. + +:::tip Fun Fact +Because Mercurial is written largely in **Python**, it is very easy for developers to write their own custom extensions to change how the tool works! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/version-control-systems/svn.mdx b/absolute-beginners/backend-beginner/version-control-systems/svn.mdx new file mode 100644 index 0000000..9613061 --- /dev/null +++ b/absolute-beginners/backend-beginner/version-control-systems/svn.mdx @@ -0,0 +1,93 @@ +--- +sidebar_position: 3 +title: "SVN - The Enterprise Classic" +sidebar_label: "3. SVN (Apache Subversion)" +description: "Learn about Centralized Version Control with Apache Subversion (SVN)." +--- + +Before Git existed, **SVN** was the industry standard. It is a **Centralized Version Control System (CVCS)**. Unlike Git, where everyone has a full copy of the project, SVN relies on a **single central server** that holds all the versions of your code. + +## The Centralized Model + +In SVN, you don't "clone" a whole history. Instead, you "checkout" a working copy of the current code from the server. When you make changes, you commit them directly back to that central server. + +```mermaid +graph TD + Server[("Central SVN Server (History)")] + UserA["Developer A (Local Copy)"] + UserB["Developer B (Local Copy)"] + UserC["Developer C (Local Copy)"] + + UserA <-->|Commit/Update| Server + UserB <-->|Commit/Update| Server + UserC <-->|Commit/Update| Server + +``` + +## Why do companies still use SVN? + +If Git is so popular, why does SVN still exist? Here are the primary use cases: + +1. **Massive Files:** Git struggles with very large binary files (like 4K video assets or high-res 3D models). SVN handles them with ease. +2. **Granular Permissions:** You can restrict access to specific folders within a project. In Git, if you have access to the repo, you usually have access to everything. +3. **File Locking:** SVN allows you to "Lock" a file. This tells your teammates: *"I am editing this file right now, please don't touch it."* This is great for files that can't be merged easily (like Photoshop files). + +## Essential SVN Commands + +The vocabulary in SVN is slightly different from Git. Let's look at the most common actions: + + + + +```bash +# 1. Get the code from the server for the first time +svn checkout http://svn.example.com/repos/project + +# 2. Get the latest changes from your teammates +svn update + +# 3. See what you have changed locally +svn status + +# 4. Save your changes to the central server +svn commit -m "docs: updated the README file" + +``` + + + + +Most Windows developers use **TortoiseSVN**, which integrates directly into your File Explorer: + +1. **Update:** Right-click a folder and select **SVN Update**. +2. **Commit:** Right-click, select **SVN Commit**, and type your message. +3. **Icons:** SVN adds small overlays to your icons (Green check = Saved, Red exclamation = Modified). + + + + +## SVN vs. Git: The Key Differences + +| Feature | SVN (Centralized) | Git (Distributed) | +| --- | --- | --- | +| **History** | Stored ONLY on the server. | Stored on every developer's machine. | +| **Offline Work** | Limited. You need internet to commit. | Full. You can commit/branch offline. | +| **Speed** | Can be slow (depends on network). | Very fast (most operations are local). | +| **Branching** | Possible, but "heavy" and complex. | Extremely lightweight and easy. | + +## Recommended Resources + +* **[Version Control with Subversion](https://svnbook.red-bean.com/)**: The official free book (often called the "Red Bean" book). +* **[Apache Subversion FAQ](https://subversion.apache.org/faq.html)**: Quick answers to common technical hurdles. +* **[TortoiseSVN Guide](https://tortoisesvn.net/support.html)**: The best resource for Windows users. + +## Summary Checklist + +* [x] I understand that SVN uses a single central server. +* [x] I know the difference between `svn checkout` (getting code) and `svn update` (syncing code). +* [x] I understand when to choose SVN over Git (large files, folder permissions). +* [x] I recognize the "Locking" feature used for binary files. + +:::warning Important Note +Because SVN is centralized, if the server goes down, you **cannot** commit your work or see the project history until it is back online. Always make sure your server is backed up! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/version-control-systems/vcs-faq.mdx b/absolute-beginners/backend-beginner/version-control-systems/vcs-faq.mdx new file mode 100644 index 0000000..8bd370a --- /dev/null +++ b/absolute-beginners/backend-beginner/version-control-systems/vcs-faq.mdx @@ -0,0 +1,95 @@ +--- +sidebar_position: 5 +title: "VCS FAQ & Common Doubts" +sidebar_label: "5. FAQ" +description: "Clearing up common confusion for beginners learning Version Control Systems." +--- + +Learning Version Control is like learning to drive, it feels overwhelming at first, but soon it becomes second nature. Here are the most common questions we get from learners at **CodeHarborHub**. + +## The Big Concept Questions + +
+1. Is Git the same thing as GitHub? +
+No! This is the most common mistake. + +Analogy: Git is the Camera; GitHub is Instagram. You use the camera to take the photo, and Instagram to share it with the world. +
+ +
+2. If I use a Distributed VCS (Git), do I still need the Cloud? +
+Technically, no. You can use Git entirely on your local machine to keep track of your own history. However, using a cloud provider like GitHub acts as a Backup and allows for Collaboration with other developers. +
+ +
+3. What happens if two people edit the same line of code? +
+This creates a Merge Conflict. The VCS will stop and ask you to "Resolve" it. It will show you both versions of the code side-by-side and ask you to pick which one to keep (or combine both). + +
+ +## Practical Workflow Questions + +
+4. How often should I "Commit" my code? +
+Rule of thumb: Commit every time you finish a small, logical task. +
+✅ Good: "Add login button styling" +
+❌ Bad: "Worked for 5 hours and changed 20 files." +
+Small commits make it much easier to find bugs later! +
+ +
+5. I accidentally committed a password or secret key! What do I do? +
+Stop! Do not just delete it and commit again. The password is still in your history. You must use tools like `git filter-repo` or "BFG Repo-Cleaner" to scrub it from the entire history. Better yet: Use a .gitignore file from the start to prevent secrets from being tracked. +
+ +
+6. Should I use the Terminal or a GUI (Desktop App)? +
+Both are fine! + +At CodeHarborHub, we recommend learning the basic terminal commands first so you understand what the buttons in the GUI are actually doing. +
+ +## Comparison Doubts + +
+7. Why is everyone moving away from SVN to Git? +
+Mainly because of Branching. In SVN, creating a branch is "heavy" and slow. In Git, it is near-instant. Modern software development relies on fast experimentation, which makes Git's speed a huge advantage. +
+ +## Summary Comparison + +```mermaid +graph TD + A[Is your project for...] --> B{Massive Files/Binaries?} + B -- Yes --> C[Use SVN] + B -- No --> D{Need Simplicity?} + D -- Yes --> E[Use Mercurial] + D -- No --> F[Use Git - Industry Standard] + +``` + +## Final Advice for Beginners + +1. **Don't Panic:** If you get a scary error message, Google it. Every developer has been stuck on a "Merge Conflict" or a "Detached HEAD" before. +2. **Read your Diffs:** Before you commit, look at what you changed. It helps you catch "console.log" statements or temporary notes you forgot to delete. +3. **The `.gitignore` is your friend:** Always include one to keep your `node_modules` or `__pycache__` out of your repository. + +:::success Module Complete! +You now have the theoretical knowledge of Version Control. You know the **What, Why, and How**. +::: \ No newline at end of file