Git: Time Travel For Your Code Course

01

What Is Git & Why Should You Care

Your code has a time machine now. You can go back before you broke everything. Which you will. Often.

🧠 Note for the confused:
Git is time travel for your code. You mess up? git checkout says 'nah, go back to when things worked.' It's like having a save button for your entire project. Why don't real games have this?

# Check if Git is installed
git --version

# First-time setup (do this ONCE)
git config --global user.name "Mayank Basena"
git config --global user.email "0mayankbasena@gmail.com"
git config --global init.defaultBranch main  # master is old news

# Check current config
git config --list

# Git terminology:
# Repository (repo) = your project folder + history
# Commit = a save point
# Branch = alternate timeline
# HEAD = where you are right now
# Working directory = your actual files
# Staging area = files waiting to be saved

02

Starting A Repo: Making Your Code Official

git init creates a repo. git add stages files. git commit saves them forever (or until you mess with history).

🧠 Note for the confused:
git init creates a new Git repository. It's like planting a flag and saying 'THIS IS MY CODE NOW. I CONTROL ITS HISTORY.' Your code now has a past. And a future. And identity issues.

# Start a new repository
mkdir my-project
cd my-project
git init  # creates .git folder (the time machine)

# Check status (your best friend)
git status

# Create a file, then add it
echo "Hello Git" > README.md
git add README.md          # stage the file
git add .                  # stage EVERYTHING
git add -A                 # stage all changes including deletes

# Commit (save point)
git commit -m "Initial commit: added README"  # write GOOD messages!

# Bad: "fixed stuff"
# Good: "Fix login bug where passwords > 20 chars crashed server"

03

Commits: Your Code's Diary

Each commit is a snapshot. git log shows your history. git diff shows changes. Good commit messages are like leaving notes for your future self (who WILL forget).

🧠 Note for the confused:
git add puts files in the 'staging area' (like a waiting room). git commit saves them forever (like taking a photo). 'git commit -m "fixed everything"' - you'll write this message a LOT.

# See your history
git log                     # full log
git log --oneline           # compact view
git log --oneline --graph   # with branch visualization
git log --author="Mayank"
git log --since="2 weeks ago"

# See what changed
git diff                    # unstaged changes
git diff --staged           # staged changes
git diff HEAD~2..HEAD       # last 2 commits

# Undo things
git checkout -- file.txt    # discard changes to file
git reset HEAD file.txt     # unstage file
git commit --amend -m "New message"  # fix last commit message

# See who broke everything
git blame file.txt          # blame each line

04

Remote Repos & GitHub: Your Code In The Cloud

GitHub is Facebook for code. git push sends your changes. git pull downloads theirs. If you get a merge conflict, the code Gods are testing you.

🧠 Note for the confused:
git push uploads your changes to GitHub. It's like sending your homework to the cloud. git pull downloads changes. It's like getting the corrected version back. Hopefully with less red ink.

# Connect to GitHub
git remote add origin https://github.com/mayank-dev-15/mayank-portfolio.git

# Push (send)
git push -u origin main   # -u sets upstream (first time)
git push                   # after upstream is set

# Pull (receive)
git pull                    # fetch + merge in one command
git fetch                   # just check what's new, don't merge

# Clone (download a repo)
git clone https://github.com/user/repo.git

# Check remotes
git remote -v

# .gitignore: don't track these files
echo "node_modules/" >> .gitignore
echo ".env" >> .gitignore

# Status check before pushing
git status && git log --oneline -3

05

Branches: Multiverse Theory For Code

Branches let you work on features without breaking the main code. It's like having a parallel universe where you actually get things right.

🧠 Note for the confused:
Branches are like alternate universes for your code. 'git branch feature-x' creates a world where you're building that cool feature. If it breaks, main universe is unaffected. It's the multiverse theory made practical.

# Branch basics
git branch                  # list branches (* = current)
git branch feature-login    # create branch
git checkout feature-login # switch to branch
git checkout -b feature-login  # create AND switch

# Merge (bring changes from one branch to another)
git checkout main           # go to main first
git merge feature-login     # merge feature into main

# Delete branch after merge
git branch -d feature-login  # safe delete
git branch -D feature-login  # force delete (changes not merged)

# See all branches including remote
git branch -a

# Rename branch
git branch -m old-name new-name

06

Merge Conflicts: When Git Says 'You Figure It Out'

Two people edited the same line. Git gives up. Now YOU must resolve it. Welcome to software engineering.

🧠 Note for the confused:
Merge conflicts happen when two people change the same part of a file. Git throws its hands up and says 'I dunno, YOU figure it out.' It's like siblings fighting over the last cookie, but with code.

# When conflict happens, git marks the file:
# <<<<<<< HEAD
# your changes
# =======
# their changes
# >>>>>>> branch-name

# 1. Open the file in editor
# 2. Keep what you want, delete the rest (including <<< === >>>)
# 3. Save the file
# 4. Mark as resolved:
git add file.txt
git commit -m "Resolve merge conflict in file.txt"

# Abort merge (run away!)
git merge --abort

# Stash (save work for later)
git stash                  # save current changes
git stash list             # see stashes
git stash pop              # restore latest stash
git stash drop             # delete stash

# Visual tools
gitk                        # GUI history viewer
git log --graph --oneline --all  # ASCII art branch history