Let's Talk About a Nightmare

We've all been here:

• MyProject.js
• MyProject_working.js
• MyProject_backup_monday.js
• MyProject_final.js
• MyProject_final_for_real.js

Quetions for you:

1. Which one is the actual final version?
2. What did you change between _final and _final_for_real?
3. How do you undo a mistake you made in all of them?
4. How do you share this with a friend so you can both work on it at the same time without creating MyProject_final_for_real_EMEKA'S_COPY.js?

This is chaos. This is unprofessional. Today, we end this chaos forever.

Acquiring Your Most Important Tool

Before we can begin, we must acquire and configure our primary tool: Git. This is a one-time setup for your machine. We will also introduce ourselves to Git so it knows who is writing the history.

Our Goal

1. Install the Git software.
2. Verify that the installation was successful.
3. Introduce ourselves to Git so it knows who we are.

Git Installation on Linux

Linux makes this incredibly simple using its built-in package manager, apt

apt (Advanced Package Tool) is Ubuntu's built-in package manager. sudo stands for "Super User Do," which temporarily gives you administrative privileges to install software.

1. First, update the package list. This command downloads the latest catalog of available software, ensuring you get a recent version of Git.

                   
                     sudo apt update
                   
                 

2. Now, install Git. This command finds the "git" package in the catalog and installs it.

                   
                     sudo apt install git
                   
                 

Universal Verification & Configuration

This step confirms the installation and sets up your identity. It is mandatory.

1. Verify: Close ALL open terminal windows and open a brand new one. This ensures your system's PATH has been updated. Type this command and press Enter:

               
                 git --version
               
             

   You must see a version number (e.g., git version 2.41.0). If you do, it worked. Else, something went wrong with the installation.

2. Configure: We must tell Git who we are. This information is baked into every commit (snapshot) you create. It's how you get credit for your work.

     
       # Use your actual name, in quotes
       git config --global user.name "Your Name"
   
       # Use the email you signed up to GitHub with, in quotes
       git config --global user.email "you@example.com"
     
                   

• What is --global? This flag tells Git to write this configuration to a special file in your user's home directory (e.g., ~/.gitconfig). This setting will apply to every single Git project on your computer. You only need to do this once.

The Pain We've All Felt

report_final.doc

report_final_v2_USE_THIS_ONE.doc

report_final_v3_janes_edits.doc

This is a system based on hope and file names. It is prone to error, confusion, and data loss. As professionals, we need an engineered solution. That solution is a Version Control System (VCS).

The Magic Time-Traveling Notebook

Imagine your project folder is a magic notebook.

• Every time you reach a good stopping point, you tell the notebook, "Take a snapshot!"
• The notebook takes a perfect, instantaneous photograph of every file and folder exactly as it is. It pastes this photo onto a new page.
• Below the photo, you write a short message explaining what you changed.
• Each page is magically chained to the previous one, creating an unbreakable history.
• You can, at any time, open the notebook to any page and your project folder will instantly revert to that state.
• You can even create a "copy" of a page and start a new chapter, experimenting with an idea without messing up your main story.

Git is this magic notebook.

The summary of a
Version Control System (VCS)

• It gives you a perfect history.
• It lets you go back to any previous page (photograph).
• It lets you see exactly what changed between pages, and who made those changes.

Git is Your Private Universe

For now, forget the internet. Forget collaboration. Git is a tool that works 100% on your local machine. It is your private time machine for your project. Everything we do in this module happens only on your computer.

We will master the local universe first. This includes:

1. Creating a repository (a new universe).
2. Saving snapshots of our work (recording history).
3. Traveling through time to view past snapshots.
4. Creating and exploring parallel universes (branching).
5. Fusing those parallel universes back into one (merging).

The Three Trees: The "Kitchen Analogy"

To master Git, you must internalize its three distinct areas.

1. Working Directory
   • The Analogy: Your entire kitchen. It's where you have all your ingredients, pots, and pans. It's where the work happens, and it's usually messy.
   • The Reality: The project folder on your computer. You can create, edit, and delete files here. Git is aware of this area, but it doesn't permanently record anything that happens here until you tell it to.

2. Staging Area (The Index)
   • The Analogy: Your clean cutting board. Before you take a photo for your cookbook, you don't just photograph the whole messy kitchen. You carefully select specific prepared ingredients and arrange them neatly on the cutting board. This is your "staged" photo.
   • The Reality: A special holding area. When you use the git add command, you are telling Git, "Take this specific change I made and place it on the Staging Area. It is now ready to be included in my next snapshot."

3. Repository (.git folder)
   • The Analogy: The beautiful, printed cookbook. Once you take the photo of your staged ingredients on the cutting board, you print it on a new page and add it to the book. This page is permanent. You can't un-print it.
   • The Reality: The hidden .git subdirectory inside your project. When you use git commit, Git takes everything on the Staging Area, creates a permanent snapshot (a commit), and stores it forever in the .git directory. This is your project's sacred history.

The Rhythm of Git: The Core Workflow

This four-command sequence will become muscle memory.

1. git init - Get a new cookbook. Run this ONCE at the very beginning of a project. It creates the magic .git folder.

2. git status - Check your surroundings. This is your best friend. It tells you what branch you're on, what files are changed but not staged, and what files are staged but not committed. Run this constantly. You can never break anything with git status.

3. git add <filename> or git add . - Prepare the ingredients.

   • git add <filename> : Puts a single file's changes onto the Staging Area. (Placing one ingredient on the cutting board).
   • git add . : A powerful shortcut that stages ALL changed files in the current directory and subdirectories. (Scooping everything from your counter onto the cutting board).

4. git commit -m "Your message" - Take the snapshot.

   • commit : The command to create the permanent snapshot.
   • -m : A "flag" that stands for "message." It tells the commit command that you're providing the descriptive message on the same line.
   • What if you forget -m? If you just type git commit, Git will open the default text editor you configured (e.g., VS Code, vim, or nano) and ask you to write a longer message there.

Writing Professional Commit Messages

Your commit history tells a story. Make it a good one.
We use a format called Conventional Commits.

Format: <type>(<scope>): <subject>

You have made your first commit. You have saved the first page in your project's history. How do you look at it?

            
$ git log
              
commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 (HEAD -> main)
Author: Your Name 
Date:   Mon Aug 25 01:45:00 2025 +0100

feat: Create initial recipe file
            
          

• commit a1b2c3d4e5f6...: This long string of characters is the commit hash. It is a unique 40-character ID (generated using a SHA-1 hash algorithm) for this exact snapshot. Think of it as the page number in your magic notebook. It is mathematically guaranteed to be unique. You will often use the first 7-10 characters to refer to a commit, which is usually enough to be unique within a project.

• (HEAD -> main): This is one of the most important concepts.
  • HEAD is a special pointer. It answers the question, "Where am I right now?" HEAD always points to the very last thing that happened in your current branch. It's the "You Are Here" marker on your project's timeline.
  • -> main tells you that HEAD is currently pointing to the tip of the main branch.

• Author: The name and email you set up in git config. This is why that step was so important.
• Date: The exact timestamp when this commit was made.
• The Commit Message: The descriptive message you wrote, indented for clarity.

A Better View of History

The default git log can be very verbose.
Here are some incredibly useful flags to customize the view:

• git log --oneline: This is the best way to get a quick overview of your project's history. It condenses each commit to a single line.

                  
    $ git log --oneline
    a1b2c3d (HEAD -> main) feat: Create initial recipe file
                  
                

• git log --graph: This will draw a little ASCII art graph in the terminal showing how the branches diverge and merge. It's not useful now, but it will become invaluable when we start branching.

• git log --stat: This shows the list of files that were changed in each commit, as well as how many lines were added or removed.

You can even combine them! A common and powerful alias many developers use is git log --oneline --graph --all

The Multiverse: Branching

The Sacred Timeline: The main Branch

Creating a Parallel Universe: Branching

So how do we do work? We create a branch.

A branch is a separate, isolated, parallel timeline. It's a "What If...?" universe where you can safely work on a new feature or experiment with an idea.

• When you create a branch, you are creating a lightweight, movable pointer that starts at the exact commit you're currently on.
• As you make new commits on this branch, your new timeline moves forward, completely independent of the main timeline.
• It is incredibly fast and cheap to create branches in Git. Professional developers create branches for everything, even a one-line bug fix.

Commands:

• git branch <branch-name>: This creates a new branch pointer but does not switch you to it. (Like drawing a door to a new universe but not walking through it).
• git checkout <branch-name>: This switches your HEAD pointer and your working directory to the specified branch. (Like walking through the door).

The Portal Gun: git checkout -b

You will almost never use git branch and git checkout separately. There is a far more convenient command that does both at once.

            
              git checkout -b <branch-name>
            
          

• -b: This flag stands for "branch." It tells the checkout command, "I want you to create a new branch with this name, and then immediately switch me to it."
• This is your "portal gun." It creates a new parallel universe and teleports you into it in one smooth action.

Let's see it in action:

            
            # We are on the main timeline
            $ git status
            On branch main

            # Let's create a new feature branch 
            # to add a user login system
            $ git checkout -b feat/user-login
            Switched to a new branch 'feat/user-login'

            # The portal gun worked!
            $ git status
            On branch feat/user-login
            
          

Now, if you create a file called login.js, add it, and commit it, that commit will exist only in the feat/user-login timeline. If you were to git checkout main, login.js would instantly disappear from your file system, because it does not exist in the main timeline's history. This is the magic of branches in action.

Fusing Timelines: Merging

The Happy Path: Fast-Forward Merge

The Two-Step Merge Dance:

1. Return to the timeline you want to update. This is the branch that will receive the changes.

                   
                   git checkout main
                 
               

2. Return to the timeline you want to update. This is the branch that will receive the changes.

                   
                   git merge feat/user-login
                 
               

The main branch pointer will simply "fast-forward" to the same commit as your feature branch tip.

The Real World: Three-Way Merge

How it works: Git looks at three commits:

1. The tip of your feature branch.
2. The tip of the main branch.
3. The common ancestor commit where your branch originally split off from main.

What is GitHub?

It's time to go online. If Git is your private notebook, GitHub is the world's largest library, coffee shop, and town square for developers.

GitHub is a website that provides hosting for your Git repositories. But it's so much more:

• A Cloud Backup: It's the primary way to back up your local repositories. If your laptop is lost, your code is safe on GitHub.
• A Collaboration Hub: It's where teams coordinate, review code, and manage projects.
• A Professional Portfolio: Your GitHub profile is your modern resume. It showcases your work, your skills, and your contributions to the community.
• A Social Network: You can "follow" other developers, "star" projects you like, and participate in discussions.

The Anatomy of a GitHub Repository

Let's take a guided tour. When you go to a repository on GitHub (e.g., github.com/nestjs/nest), you'll see this: