Git, GitHub & Terminal

Before you write another line of application code, learn the tool that saves you from yourself. Git records snapshots of your project. You can experiment freely because every working version is recoverable, and you can collaborate without emailing zip files.

GitHub is where those snapshots live when you want to share them. Git is the tool; GitHub is the hosting service. This lesson covers the terminal basics, the Git workflow, branching, pull requests, and the commands you will type thousands of times.

The terminal in ten commands

The terminal looks intimidating for about twenty minutes, then becomes faster than any file manager. These ten commands are 95% of daily use:

pwd                 # where am I?
ls                  # what is here?
cd projects         # enter the folder "projects"
cd ..               # go up one level
mkdir portfolio     # create a folder
touch index.html    # create an empty file
cat README.md       # print a file's contents
rm old-notes.txt    # delete a file
clear               # clear the screen

Two habits save enormous time:

• Tab completion — type the first letters of a file or folder and press Tab. The shell completes it and prevents typos.
• Arrow up — cycles through previous commands. Ctrl+C cancels whatever is running.

What Git is and why you want it

A Git repository is a hidden .git folder inside your project that stores the entire history: every commit, every branch, every change. It works fully offline. GitHub merely receives a copy when you push.

With Git you can:

• See exactly what changed since yesterday.
• Return to any previous working state.
• Try an idea on a branch; if it fails, delete the branch.
• Collaborate without anyone overwriting anyone else.

Without it, “final_v2_REALLY_final.zip” is your version control system.

One-time setup

Tell Git who you are. These values appear in every commit:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Check the result with git config --list.

Your first repository

mkdir portfolio
cd portfolio
git init
git status

git init creates the hidden .git folder. git status is the command you will run constantly — it tells you what is untracked, staged, or changed.

Create a .gitignore before your first commit. It lists files Git should pretend do not exist:

node_modules/
.env
.env.local
dist/
build/
.DS_Store

Never commit node_modules (thousands of files, regenerated by npm install) or .env files (they contain secrets). If a secret ever lands in a commit, consider it leaked — rotate it.

The three areas

Every Git workflow moves changes through three places:

Working directory          Staging area             Repository
(your files)     --add-->  (next commit)  --commit--> (history)

• Working directory — the files you edit.
• Staging area — the changes you have chosen for the next commit.
• Repository — the permanent history of commits.

The staging area is what makes Git powerful: you commit exactly what you mean to, one logical change at a time.

git add index.html      # stage one file
git add .               # stage everything changed
 
git status              # review what is staged
 
git commit -m "Add hero section to landing page"
git log --oneline       # history, one line per commit

Inspecting changes

git diff                 # unstaged changes, line by line
git diff --staged        # what will go into the next commit
git show HEAD            # the most recent commit
git log --oneline --graph --all  # compact history with branches

Read the diff before every commit. It is how you catch debug console.logs, accidental secrets, and half-finished edits.

Undoing things

git restore index.html          # discard uncommitted changes to a file
git restore --staged index.html # unstage, keep the changes
git commit --amend -m "Better message"  # rewrite the last commit
git revert a1b2c3               # new commit that undoes an old one

Branching

A branch is a movable pointer to a commit. Creating one is instant and cheap, so use them for everything:

git switch -c feature/nav    # create and switch to a branch
# ... edit files, add, commit ...
 
git switch main              # back to the main line
git merge feature/nav        # bring the branch's commits into main
git branch -d feature/nav    # delete the merged branch

If two branches edit the same lines, you get a merge conflict. Git writes both versions into the file:

<<<<<<< HEAD
<button class="primary">Save</button>
=======
<button class="cta">Save changes</button>
>>>>>>> feature/nav

To resolve it: open the file, keep the correct content, delete the <<<<<<<, =======, and >>>>>>> lines, then git add and git commit. Conflicts are normal, not errors.

GitHub and remotes

A remote is a named copy of your repository somewhere else. The conventional name for the main one is origin.

1. Create an empty repository on GitHub (skip the README — you already have commits).
2. Connect it and push:

git remote add origin https://github.com/YOUR-USERNAME/portfolio.git
git push -u origin main

• -u links your local main to origin/main, so future pushes are just git push.
• GitHub does not accept account passwords for Git operations. Use a personal access token (Settings → Developer settings) or an SSH key. The GitHub CLI (gh auth login) configures either for you.

Other essentials:

git clone https://github.com/user/repo.git  # download a repository
git pull                                     # fetch + merge remote changes
git remote -v                                # list remotes

The pull request workflow

A pull request (PR) asks to merge one branch into another, with review and discussion attached. Even when working alone, PRs give you a second look and a clean history.

1. git switch -c feature/about-page   (branch from main)
2. edit, add, commit
3. git push -u origin feature/about-page
4. open the PR on GitHub, describe what changed and why
5. review, request changes, approve
6. merge on GitHub, delete the branch
7. git switch main && git pull

Small PRs get reviewed quickly; giant PRs sit for weeks. Keep each one to a single purpose.

Commit hygiene

You are writing history for your future self:

• One logical change per commit. “Add nav” and “Fix footer typo” are two commits.
• Imperative subject, under ~50 characters: “Add login form”, not “Added some stuff”.
• Body explains why, not what — the diff already shows what.
• Commit often. Small commits are easy to review, revert, and understand months later.
• Never commit secrets, dependencies, or build output.

Try it

mkdir git-practice
cd git-practice
git init
 
echo "# My first repo" > README.md
git status
git add README.md
git commit -m "Add README"
 
git log --oneline

Check your understanding

Summary

• The terminal commands pwd, ls, cd, mkdir, touch, and cat cover daily navigation.
• Git stores snapshots; GitHub hosts a copy. They are different things.
• Changes flow working directory → staging area → repository via add and commit.
• git status and git diff are the commands that keep you honest.
• git restore, --amend, and revert handle most mistakes; reset --hard deletes work.
• Branches are cheap; keep main working and merge finished features.
• Pull requests are the collaboration unit: small, focused, reviewed.

You now have the workflow professionals use every day. Time to use it on a real project: your portfolio.