Git & GitHub Basics

The problem Git solves

Have you ever saved files named index-final.html, index-final-2.html, index-REALLY-final.html? That is version control done badly. Git is a tool that records the full history of your project automatically: every saved version (called a commit) is kept, so you can see what changed, when, and roll back to any earlier point if you break something.

Think of Git as save points in a video game. Every commit is a checkpoint. Mess up later? Load an earlier checkpoint. Want to see exactly what you changed between two points? Git shows you, line by line.

Git vs GitHub — not the same thing

Install and identify yourself (one-time setup)

Install Git from git-scm.com (the VS Code installer offers it too). Then, once ever, tell Git your name and email so it can label your commits. Run these in a terminal — they are not HTML, so there is no live preview; the output is shown after each.

git --version
git config --global user.name "Asha Sharma"
git config --global user.email "asha@example.com"

Line by line: git --version checks Git is installed and prints its version. The two git config --global lines store your name and email so every commit you ever make is signed with them. --global means “for all my projects”, so you only do this once per computer.

Track a project: the four core commands

Imagine you have a folder my-site with an index.html inside. Here is the everyday Git workflow that turns it into a tracked project with its first save point.

git init
git add index.html
git commit -m "Add homepage with heading and intro"
git status

Walking through each command:

1. git init — start tracking this folder. Git creates a hidden .git folder to store the history.
2. git add index.html — stage the file: tell Git “include this in my next save point.” (Use git add . to stage every changed file at once.)
3. git commit -m "..." — create the save point with a short message describing what changed. This is the commit.
4. git status — ask Git what is going on: which files changed, what is staged, what is committed.

That last line, “nothing to commit, working tree clean,” is what you want to see — it means every change is safely saved. The terms: stage = pick what goes into the next commit; commit = the saved snapshot; repository (or repo) = the whole tracked project including its history.

Ignore files you should not track

Some files do not belong in version control — system junk, secret passwords, huge generated folders. Create a file named .gitignore listing them, and Git pretends they do not exist.

# .gitignore — one pattern per line
.DS_Store
node_modules/
*.log
.env

Each line is a pattern Git will skip: .DS_Store is a Mac system file, node_modules/ is a huge folder you can always re-download, *.log matches any log file, and .env holds secret keys you must never publish. Lines starting with # are comments. For a plain HTML site, ignoring .DS_Store alone is often enough.

Push your project to GitHub

Now put your local repo online. First create an empty repository on github.com (sign up free, click New repository, give it a name like my-site, and do not add a README so it stays empty). GitHub then shows you commands to connect your folder — they look like this:

git remote add origin https://github.com/yourname/my-site.git
git branch -M main
git push -u origin main

Step by step: git remote add origin <url> tells your local Git where the online copy lives, nicknaming it origin. git branch -M main names your main line of work main (the modern default). git push -u origin main uploads your commits to GitHub; the -u links the two so that next time you can just type git push.

The everyday loop

Once set up, daily work is a short cycle you will repeat thousands of times:

1. Edit your files in VS Code.
2. git add . to stage what changed.
3. git commit -m "Describe the change" to save a checkpoint.
4. git push to send it up to GitHub.