🗂️ The Staging Model, .gitignore & Remotes

The Three Trees

The single most useful thing you can learn about Git is that it manages three trees — three snapshots of your project that Git constantly compares. When you understand what each holds, git status reads like plain English and confusing commands click into place.

When git status says "Changes not staged for commit," it means the working directory differs from the staging area. "Changes to be committed" means the staging area differs from the last commit. It's always comparing two of the three trees.

Staging Precisely

Beginners reach for git add . every time, but the staging area's real power is selectivity — building a commit out of exactly the changes that belong together, even if you touched a dozen files.

git add index.html          # stage one file
git add css/ js/            # stage whole folders
git add "*.js"             # stage all JavaScript files
git add .                  # stage everything changed below the current folder
git add -p                 # review each change chunk and choose y/n interactively

The -p (patch) flag is a hidden gem. It walks you through each hunk of changes and asks whether to stage it. That lets you split a messy editing session into clean, single-purpose commits — stage the bug fix now, leave the half-finished feature for later.

Un-staging & Restoring

Staged the wrong file? Edited something you wish you hadn't? Modern Git gives you two clear, purpose-built commands: git restore for undoing changes and git restore --staged for un-staging. (Older tutorials use git checkout and git reset for these; the newer verbs are less error-prone and are what you should reach for.)

Un-stage a file (keep your edits)

# Oops — added a file I didn't mean to include in this commit
git restore --staged secrets.env
# The edits are safe; the file is just no longer staged

Explanation: This moves a change from the staging area back to the working directory. Your file's contents are untouched — you've only changed Git's mind about the next commit.

Discard uncommitted edits (throw the changes away)

# Discard changes to a file, reverting it to the last commit
git restore index.html

Reading the diagram: add pushes right, restore --staged pulls a change back out of staging, and restore <file> overwrites your working file with the committed version.

Keeping Junk Out: .gitignore

Not every file belongs in version control. Dependency folders, build output, editor settings, and — critically — secret credentials should never be committed. A .gitignore file tells Git which paths to pretend it can't see.

Create a file literally named .gitignore in your project root and list patterns, one per line:

# Dependencies — huge and re-installable, never commit these
node_modules/

# Build output
dist/
build/

# Secrets and environment variables
.env
.env.local
*.key

# OS and editor cruft
.DS_Store
.vscode/
Thumbs.db

# Logs
*.log
npm-debug.log*

Why it matters: committing node_modules/ bloats your repo with thousands of files anyone can reinstall in seconds with npm install. Committing a .env can leak API keys and database passwords to the entire internet the moment you push. The .gitignore is your first line of defense.

git rm --cached .env
git commit -m "Stop tracking .env and ignore it"

Cloning an Existing Project

So far you've created repos from scratch. Just as often, you'll clone — download a complete copy of a repository that already exists on GitHub, including its entire history and its remote connection, all in one command.

git clone https://github.com/yourname/portfolio-site.git

# Clone into a folder with a different name
git clone https://github.com/yourname/portfolio-site.git my-copy

What cloning sets up for you: a new folder containing the project, a full .git history, and — importantly — a remote called origin already pointing at the URL you cloned from. So after a clone you can immediately git pull and git push with no git remote add needed. Cloning is init plus remote add plus a full download, bundled together.

Managing Remotes

A remote is a named URL pointing at a hosted copy of your repo. Most projects have exactly one, called origin, but the git remote family lets you inspect and manage them.

git remote -v                 # list remotes with their URLs
git remote add origin URL      # add a new remote named origin
git remote rename origin upstream   # rename a remote
git remote remove origin       # remove a remote
git remote set-url origin URL  # point an existing remote at a new URL

origin    https://github.com/yourname/portfolio-site.git (fetch)
origin    https://github.com/yourname/portfolio-site.git (push)

The set-url command is the one you'll want when switching a repo from HTTPS to SSH, or after transferring a repository to a new owner:

# Switch from HTTPS to SSH so you stop being prompted for credentials
git remote set-url origin git@github.com:yourname/portfolio-site.git

Linking a Folder to an Existing Repo

A common real situation: you already have an empty (or matching) repository on GitHub, and a local project folder you want to connect to it. The sequence is the same building blocks you now know:

# 1. Initialize Git in the project folder (if not already a repo)
git init

# 2. Stage and commit the project's current state
git add .
git commit -m "Initial project setup"

# 3. Point it at the existing GitHub repository
git remote add origin https://github.com/yourname/existing-repo.git

# 4. Push, setting the upstream link
git push -u origin main

If the remote already had commits (say a README you created on GitHub), step 4 is rejected. Reconcile the histories first:

git pull origin main --allow-unrelated-histories
# resolve any conflicts, then:
git push -u origin main

The --allow-unrelated-histories flag tells Git it's fine to merge two histories that started independently — exactly the case when both sides had their own first commit.

Practice & Quiz

# Create files that should be ignored
echo "SECRET=abc123" > .env
mkdir node_modules && touch node_modules/lib.js

# Ignore them
printf ".env\nnode_modules/\n" > .gitignore

git status
# .env and node_modules/ do NOT appear — only .gitignore is untracked

# Stage a file, then change your mind
git add .gitignore
git restore --staged .gitignore   # back to untracked, edits intact
git status

# Suppose you edited both a bug in app.js and styles in style.css
git add app.js
git commit -m "Fix null check in cart total"

git add style.css
git commit -m "Increase heading contrast"

git log --oneline   # two separate, self-describing commits

Best Practices & Pitfalls

✅ Do

• Add a .gitignore before your first commit, so junk never enters history
• Start from GitHub's official template for your language, then customize
• Stage selectively with git add -p to keep commits focused
• Use git restore --staged to un-stage and git restore <file> to discard — the clear modern verbs
• git clone projects you'll work on; never rely on "Download ZIP"

❌ Don't

• Commit node_modules/, build output, or .env files
• Run git restore <file> on changes you might still want — it's irreversible
• Assume adding a file to .gitignore removes an already-tracked file
• Leave every commit as "update" — a useless history is barely better than none

Summary

📚 Additional Resources

• Pro Git — Recording Changes to the Repository
• git-scm.com — gitignore documentation
• GitHub Docs — Ignoring files
• git-scm.com — git restore documentation

🚀 What's Next?

You now understand how changes flow between Git's trees and how to keep your repo clean. Next we unlock Git's real superpower: branching and collaboration — creating parallel lines of work, merging them back together, and using GitHub pull requests to build software as a team.