Git Basics: Clone, Add, Commit 🌿

# git clone copies an entire repository (files, history, and
# all branches) from a remote server down to your machine.
git clone https://github.com/user/project.git

# Clone into a custom folder name instead of "project"
git clone https://github.com/user/project.git my-folder

# After cloning, the remote connection "origin" is already set up
cd project
git remote -v

Cloning into 'project'...
remote: Enumerating objects: 156, done.
remote: Counting objects: 100% (156/156), done.
remote: Compressing objects: 100% (98/98), done.
Receiving objects: 100% (156/156), 2.40 MiB | 4.10 MiB/s, done.
Resolving deltas: 100% (54/54), done.

origin  https://github.com/user/project.git (fetch)
origin  https://github.com/user/project.git (push)

# git status is the command you'll run most. It answers:
# "What have I changed, and what is staged for the next commit?"
git status

# Tip: the short format is faster to scan once you know it.
# M = modified, A = added, ?? = untracked (Git isn't tracking it yet)
git status --short

On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   index.html

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   style.css

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        notes.txt

# The daily loop:  edit  ->  git add  ->  git commit.
# "Staging" = choosing which changes go into the NEXT snapshot.

# Three ways to stage:
git add index.html        # stage ONE specific file
git add .                 # stage everything changed in this folder & below
git add -A                # stage everything changed in the WHOLE repo
                          #   (including deletions, even outside this folder)

# Save the staged snapshot with a short, clear message:
git commit -m "Fix navbar spacing on mobile"

# Stage and commit the next change separately for a clean history:
git add style.css
git commit -m "Add dark mode colours"

[main a1b2c3d] Fix navbar spacing on mobile
 1 file changed, 6 insertions(+), 2 deletions(-)

[main d4e5f6g] Add dark mode colours
 1 file changed, 12 insertions(+), 1 deletion(-)

# 🎯 YOUR TURN — replace each ___ then run it in your terminal.
# Scenario: you edited TWO files and want them in ONE commit.

# 1) Stage BOTH changed files at once (everything in this folder)
git ___                       # 👉 the command that stages every change ( . )

# 2) Double-check what is staged before you commit
git ___                       # 👉 the command that shows what changed

# 3) Commit with a clear, present-tense message
git commit -m "___"           # 👉 e.g. "Add contact form and validation"

# ✅ Expected output (example):
#    [main 7c3d9a1] Add contact form and validation
#     2 files changed, 24 insertions(+), 3 deletions(-)

# git log shows the commit history, newest first.
# The full log is verbose, so most people use --oneline:
git log --oneline

# Add --graph to draw the branch/merge structure as ASCII art:
git log --oneline --graph

# Combine flags for a readable project map:
git log --oneline --graph --all

d4e5f6g Add dark mode colours
a1b2c3d Fix navbar spacing on mobile
x9y8z7w Add user profile page
m3n4o5p Set up React Router
j7k8l9q Initial commit

*   9f2e1c8 Merge branch 'feature/profile'
|\
| * x9y8z7w Add user profile page
|/
* m3n4o5p Set up React Router
* j7k8l9q Initial commit

# git diff shows your changes line by line:
#   - red lines (-) were removed,  green lines (+) were added.

git diff              # WORKING tree vs staged  (changes you have NOT staged)
git diff --staged     # STAGED  vs last commit  (what the commit will contain)

# Typical flow: review the diff, then stage, then review the staged diff:
git diff              # "did I leave a debug line in?"
git add style.css
git diff --staged     # "yes, this is exactly what I want to commit"

diff --git a/style.css b/style.css
index 83db48f..f7e1a2c 100644
--- a/style.css
+++ b/style.css
@@ -1,3 +1,4 @@
 body {
-  background: white;
+  background: #1a1a2e;
+  color: #e0e0e0;
 }

# A .gitignore file lists paths Git should NEVER track.
# Put it in the repo root. One pattern per line. Comments start with #.

# Dependencies — huge, reinstallable, never commit these:
node_modules/

# Build output:
dist/
build/

# Secrets & environment files (API keys, passwords):
.env
.env.local

# OS / editor junk:
.DS_Store
*.log

# Ignore everything in /tmp BUT keep one file:
tmp/*
!tmp/.gitkeep

# After adding the .gitignore above, untracked junk disappears:
$ git status --short
 M index.html
?? .gitignore

# node_modules/, .env and *.log are no longer listed — Git is ignoring them.

# 🎯 YOUR TURN — finish this .gitignore file.
# You ran "git status" and saw node_modules/ and secret.env listed as untracked.
# Stop Git from EVER tracking them.

# 1) Ignore the whole dependencies folder
___                           # 👉 the folder name, with a trailing slash

# 2) Ignore the secrets file so your API key never gets committed
___                           # 👉 the exact file name: secret.env

# 3) Ignore every .log file anywhere in the project
___                           # 👉 a wildcard: *.log

# ✅ Expected: after saving, "git status --short" no longer lists
#    node_modules/, secret.env, or any .log file.