Skip to Content
GuidesGit & GitHub

Git & GitHub

Git is a version control system — it tracks every change to your code so you can undo mistakes, work on features without breaking the main app, and collaborate with others. GitHub is where your Git repo lives online. Think of Git as the tool and GitHub as the cloud backup + collaboration platform.

Why you should care

  • Undo anything — every change is saved. Break something? Go back.
  • Work on features safely — branches let you experiment without affecting the live app.
  • Deploy automatically — platforms like Vercel watch your GitHub repo and deploy on every push.
  • AI tools expect it — Cursor, Copilot, and most dev workflows assume you’re using Git.

Setup (one time)

# Check if Git is installed
git --version
 
# Set your identity (use the email linked to your GitHub account)
git config --global user.name "Your Name"
git config --global user.email "you@email.com"

Create a GitHub account  if you don’t have one. Free tier is all you need.

The 10 commands you’ll use constantly

Starting a project

# Clone an existing repo from GitHub
git clone https://github.com/username/repo-name.git
 
# OR initialize Git in an existing folder
git init

The daily workflow

# 1. Check what's changed
git status
 
# 2. Stage changes (pick what to include in the next save)
git add .                    # stage everything
git add src/page.tsx         # stage one file
 
# 3. Save (commit) with a message
git commit -m "add login page"
 
# 4. Push to GitHub
git push

That’s the core loop: change → stage → commit → push. Do this multiple times a day.

Branches

# Create and switch to a new branch
git checkout -b feature/login-page
 
# Switch between existing branches
git checkout main
 
# See all branches
git branch
 
# Push a new branch to GitHub
git push -u origin feature/login-page

Syncing with others

# Get the latest changes from GitHub
git pull
 
# See the log of recent commits
git log --oneline

Key concepts

Repository (repo) — a folder tracked by Git. Contains your code + the entire history of changes.

Commit — a saved snapshot with a message. Think of it as a save point in a game. Good commit messages describe what and why: "add user authentication with Clerk" not "update stuff".

Branch — a parallel line of work. main (or master) is the primary branch. Create feature branches to work without risk: feature/login, fix/nav-bug, etc.

Staging area — the “cart” before checkout. git add puts files in the cart; git commit checks out (saves them).

Push — upload your commits to GitHub.

Pull — download the latest commits from GitHub.

Pull request (PR) — a proposal to merge one branch into another on GitHub. This is where code review happens. Even solo developers use PRs because Vercel creates preview deployments for each one.

Merge — combine one branch’s changes into another. Usually done via a PR on GitHub.

Conflict — when two branches changed the same lines. Git will ask you to manually pick which version to keep. AI tools can help resolve these.

GitHub essentials (the website)

Creating a repo

  1. Click “New” on GitHub
  2. Name it, choose public or private
  3. Don’t initialize with README if you already have local code
  4. Follow the commands GitHub shows to connect your local folder

Pull requests

  1. Push your branch to GitHub
  2. GitHub shows a “Compare & pull request” button
  3. Add a description of what changed and why
  4. Request review (or just merge it yourself for solo projects)
  5. Merge when ready — this puts your changes into main
  6. Vercel (or similar) auto-deploys from main

Issues

Use GitHub Issues to track bugs and features. Reference them in commits: "fix nav layout #12" automatically links the commit to issue #12.

Common situations

“I committed something I shouldn’t have”

# Undo the last commit but keep the changes
git reset --soft HEAD~1

“I need to discard my local changes”

# Discard changes to a specific file
git checkout -- src/page.tsx
 
# Discard ALL uncommitted changes (careful!)
git checkout -- .

“I accidentally committed my .env file”

# Remove it from Git tracking (file stays on disk)
git rm --cached .env
# Add .env to .gitignore, then commit
echo ".env" >> .gitignore
git add .gitignore .env
git commit -m "remove .env from tracking"

“I need to see what changed”

git diff                    # unstaged changes
git diff --staged           # staged changes
git log --oneline -10       # last 10 commits, compact

.gitignore — what NOT to track

Create a .gitignore file in your project root. Common entries:

node_modules/
.env
.env.local
.next/
.DS_Store

Never commit: API keys, database URLs, passwords, .env files, node_modules/.

Tips

  • Commit often — small, frequent commits are easier to undo and review than giant ones.
  • Branch names — use a prefix: feature/, fix/, chore/. It keeps things organized.
  • Write good messages — future you will thank present you. "add Stripe checkout flow" beats "updates".
  • Pull before you push — always git pull before starting work to avoid conflicts.

Last reviewed: April 2026.

Terminal essentials2026 Security Guide